DNS Resolution: From Name to IP Address

Before DNS, every host on the ARPANET downloaded one file, HOSTS.TXT, maintained by hand at the Stanford Research Institute. By the early 1980s it was too big and changed too often to copy around, so Paul Mockapetris designed a distributed, hierarchical replacement (RFC 882/883 in 1983, refined as RFC 1034/1035 in 1987, still the core specs). The design has barely changed since: authority is delegated down a tree of names, and answers are cached everywhere on the way back. The modern additions are mostly about trust and privacy: DNSSEC (DNS Security Extensions; the root zone was signed in 2010), DoT (DNS over TLS, RFC 7858, 2016) and DoH (DNS over HTTPS, RFC 8484, 2018).

You meet DNS every time you add an A record in Cloudflare or Route 53, wait for a domain to "propagate", see ENOTFOUND or NXDOMAIN in a log, or point api at a load balancer with a CNAME. The fastest way to see the whole chain is dig +trace, which does the walk itself instead of asking your resolver:

DNS is the first dependency of every request and the least visible one. A slow resolver adds latency before any TCP connection opens; a wrong TTL turns a five-minute migration into a two-day one; a CNAME mistake sends traffic to a stale load balancer; a cluster with default settings quietly multiplies every external lookup. And when DNS itself goes down, everything that depends on names goes with it, including the tools you would use to fix it: in Facebook's six-hour outage on 4 October 2021, a routing change withdrew the paths to their authoritative DNS servers, so facebook.com stopped resolving for the whole internet, and engineers had to restore access physically.

Two different kinds of question are asked. Your machine sends a recursive query: "give me the final answer". The resolver then sends iterative queries: each server answers with what it knows, usually a referral ("I don't have it, but these servers are responsible for .com"), and the resolver follows the referral itself. The root and TLD servers never do the full lookup for anyone, which is what lets a handful of them serve the whole internet.

CAA (Certification Authority Authorization) records are checked by certificate authorities before they issue. In a zone file the same records look like this; note the trailing dots, which mark a name as absolute:

Nothing is pushed when you change a record. The new value sits on your authoritative servers, and every resolver that already cached the old one keeps serving it until its copy expires. "Propagation" is just the slowest cache in the world timing out, bounded by the TTL you set before the change. A missing name is cached too: under negative caching (RFC 2308), an NXDOMAIN is remembered for the SOA's negative TTL, so querying a record before you create it can make the new record invisible for that long.

Returning different answers per query gives you coarse global balancing: several A records for round-robin, GeoDNS that answers by the resolver's location, or weighted and health-checked records in Route 53 or Cloudflare. Its limits come from caching: clients keep using whatever they got until the TTL ends, a dead server stays in caches, and the location you see is the resolver's, not the user's (EDNS Client Subnet, RFC 7871, passes a truncated client subnet to help). That is why DNS usually picks a region, and a real load balancer behind it picks the server. Public resolvers such as 1.1.1.1 (Cloudflare, 2018) and 8.8.8.8 (Google, 2009) are themselves anycast: one address announced from many locations, routed to the nearest.

Every pod gets a resolver config pointing at the cluster DNS (CoreDNS) with search domains so that orders resolves to the Service in the same namespace. The default ndots:5 means any name with fewer than five dots is tried against each search domain first, so an external lookup fans out into several failing queries, each for A and AAAA, before the real one.