A county needs Pods to resolve an on-prem Active Directory DNS zone for internal directories. How is that commonly configured with CoreDNS?
Select an answer to reveal the explanation.
Short Explanation
Teach CoreDNS about the other building: put a stub or forward for the AD zone in the CoreDNS ConfigMap so cluster Pods can ask the right external DNS for those names.
Full Explanation
When a county needs Pods to resolve an on-prem Active Directory DNS zone for internal directories, administrators commonly customize the CoreDNS ConfigMap Corefile with a stub domain or forward rule for that zone so selected queries go to the AD DNS servers. Cluster Pods keep using CoreDNS as their nameserver; only matching zones are delegated externally. That is how you teach the building directory about another agency’s names without renaming the entire Kubernetes cluster domain.
Adding the AD zone as an Ingress host rule does not configure CoreDNS forwarding—Ingress is HTTP routing, not recursive DNS policy. Renaming the cluster domain to the AD FQDN via Deployment annotations is not a stub-domain mechanism and would break Service DNS assumptions. Creating a Gateway listener named after the AD zone does not publish AD SRV records into CoreDNS.
Exam caveat: forward misconfiguration can loop or blackhole resolution—edit carefully, reload/roll CoreDNS, and ensure NetworkPolicy allows CoreDNS egress to AD resolvers. If NodeLocal DNSCache is present, it still depends on correct upstream Corefile policy.
Operational check: patch the CoreDNS ConfigMap with a forward/stub for the AD zone, rollout CoreDNS, dig an AD name from a Pod, and verify answers while confirming svc.cluster.local lookups continue to work for county Services.