How DNS works: a distributed phone book

DNS — the Domain Name System — translates domain names into IP addresses. The motivation has two layers. On the surface: humans remember names, machines recognize numbers. Deeper: decoupling. A server can change its IP, migrate data centers, or move behind a CDN while the name stays put, and the rest of the world changes nothing. Without that decoupling, every migration and every edge location would have to be tracked by every visitor.

The book cannot live on one machine — the traffic would crush it and one failure would blind everyone — so it is a distributed, layered database where each domain's owner keeps its own ledger.

One lookup, walked through. Caches first, nearest to farthest: browser cache, then the operating system's stub resolver cache, then the recursive resolver's cache. A miss at every layer starts the legwork: the recursive resolver (usually the ISP's, or a public one like 8.8.8.8) takes the whole question and runs all the legs itself. It asks the root servers, which hold no specific names and only point: that is a .com name, ask the TLD servers. The TLD servers point again: this domain is kept by these authoritative servers. The authoritative server is the domain's own ledger and gives the final answer, together with a TTL — how long every cache on the way back may keep it. The resolver carries the answer home and caches it; so does the browser.

Two words worth keeping straight: the resolver's service to you is recursive (hand it the whole question); the questions it asks upstream are iterative (one referral at a time). And the roles differ in kind: the authoritative server is the ledger; the resolver is only the courier.

Caching is licensed by the protocol, implemented by choice. Every record carries its TTL — that field exists so caches know how long an answer may be trusted. No layer is forced to cache; the browser may skip its own cache entirely. But skipping buys nothing: the OS cache and the resolver cache below it would still hold the answer, so the only effect is an extra round trip. Modern browsers go the other way and run their own DNS client, sometimes bypassing the OS stub resolver entirely (e.g. over DoH) for speed and control.

Record types. A / AAAA: name → IPv4 / IPv6 address. CNAME: name → another name (an alias). NS: declares which servers are authoritative for the domain — the referral chain above is built from these. TXT: an arbitrary text note pinned to a name; because only the domain's owner can publish one, TXT records double as proof of ownership (search-engine site verification works this way) and as the publishing channel for mail authentication rules (SPF, DKIM).

TTL is a trade-off, not a setting. Long TTL: fewer lookups, calmer authoritative servers — but a changed record only takes effect as old caches expire. Short TTL: changes land fast, at the price of constant re-asking. Pick which failure you fear.

Where it breaks: trust on the path. Classically, the first plausible answer to reach the resolver wins, so an attacker positioned on the path can race a forged answer — that is DNS poisoning. The two standard repairs fix different layers: DNSSEC signs the ledger's answers, so a forged answer fails verification (fixes false answers); DoH / DoT encrypt the leg between you and the resolver, so nobody on that path can see or inject anything (fixes the path itself). They are not substitutes for each other.