Q: How does DNS resolution work step-by-step from domain name to Kubernetes pod, and what role do root servers and CoreDNS play?
The definitive step-by-step journey of a DNS lookup: resolving root servers, TLD nameservers, authoritative nameservers, local recursive caches, and Kubernetes CoreDNS ndots:5 search path amplification.
🛠️ Production Runbook & Step-by-Step Resolution
Browser Cache & Recursive Resolver
Browser checks local memory cache -> OS resolver checks /etc/hosts and systemd-resolved -> forwards query to recursive resolver (e.g., 8.8.8.8 or AWS VPC Route 53 Resolver at VPC Base + 2).
Iterative Hierarchy: Root (.) -> TLD (.com) -> Authoritative Nameserver
Recursive resolver queries Root Nameserver (.) -> returns TLD nameserver for .com -> queries TLD nameserver -> returns Authoritative Nameserver (e.g., Route 53 ns-xxx.awsdns.com) -> returns the final A/AAAA/CNAME record with TTL.
Kubernetes Pod CoreDNS & ndots:5 Amplification
Inside Kubernetes, /etc/resolv.conf has ndots:5 and search paths (default.svc.cluster.local, svc.cluster.local, cluster.local). Any domain with fewer than 5 dots causes CoreDNS to query internal search domains first, generating up to 4 failed NXDOMAIN lookups before trying the external internet.
# /etc/resolv.conf in a pod
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5- Browser checks local OS cache before sending query to recursive resolver.
- Recursive resolver queries Root (.), then TLD (.com), then Authoritative nameserver for the A record.
- In Kubernetes, CoreDNS handles internal cluster service discovery (.cluster.local).
- Beware ndots:5: append a trailing dot (api.stripe.com.) in pods to bypass 4 redundant NXDOMAIN lookups.