Resolution · stage 02
DNS from the root
The name is resolved by walking down a hierarchy from the root, with caching at every step.
Stage 02 of six/Resolution, piece 1 of 3/Full piece/Next: TTL and staleness
How a name becomes an address — and why it takes a hierarchy to do it
Every domain name is a small bureaucratic act: it asserts membership in a hierarchy that begins, invisibly, with a single dot. That dot — the root of the DNS tree — is what makes the whole system work without any central authority needing to know every name in existence.
When a browser needs to resolve www.example.com, it does not ask a single omniscient server. It asks a series of progressively more specific ones, each delegating responsibility downward. The process is called iterative resolution, and it is defined in RFC 1034, published by the IETF in 1987. The design has barely changed since.
The walk down the tree
The first stop is whatever recursive resolver your operating system has been configured to use — typically one run by your ISP or a third-party operator. Its job is to do all the asking on your behalf and hand back a final answer.
If it has the answer cached, the query ends here. If not, it starts at the top. The recursive resolver contacts one of the root name servers — thirteen logical addresses, labelled A through M, each served by a cluster of machines spread across the globe using anycast. The root server does not know where www.example.com lives. It knows who is responsible for .com, and it says so: "Ask the .com name servers." That referral is called a delegation.
The resolver now contacts a .com TLD (top-level domain) name server, operated by Verisign. Again, no final answer — but another delegation: "Ask the authoritative name servers for example.com." Those servers were registered when the domain was bought. They hold the actual records.
The authoritative name server for example.com finally returns the A record — the IPv4 address (or AAAA for IPv6) that the browser needs to open a connection. The recursive resolver caches this answer, stores the TTL attached to each record, and passes the result back. Every layer of the hierarchy caches what it learns; the root servers themselves are almost never hit for the same query twice in quick succession on a busy resolver.
Caching, TTL and the price of a wrong answer
Each DNS record carries a TTL — time to live — measured in seconds. Once that timer expires, the cached answer is discarded and the walk begins again. Set the TTL high and changes propagate slowly; set it low and resolvers hammer the authoritative servers. The trade-off is deliberate, not accidental, and TTL and staleness is its own problem worth understanding in full.
One consequence is that there is no instant "update DNS" — when you point a domain at a new server, parts of the internet will keep reaching the old one until every resolver's cache has aged out. Operators often drop the TTL well before a planned migration to reduce that window.
The root zone is maintained by IANA, the Internet Assigned Numbers Authority, which publishes it openly.
The caching hierarchy also means an error propagates. A poisoned cache — one holding a forged answer — sends everyone the resolver serves to the wrong address until the TTL runs out. DNSSEC was designed to counter this: each response can be cryptographically signed by the zone that issued it, and resolvers that validate signatures can detect forgery. Adoption has been slow but the infrastructure for it — signing at the root, signing at the major TLDs — is largely in place.
Why thirteen? Why a dot?
The number thirteen is not mystical. It reflects the maximum payload of a UDP packet in 1987: fitting all the root server addresses into a single UDP response capped the count at thirteen. Modern anycast means each of those thirteen addresses is answered by hundreds of physical machines worldwide, so the real count of machines serving the root is far larger.
The trailing dot — the one that appears in zone files as example.com. — represents the root zone itself. End-users never type it; software adds it when constructing a fully qualified domain name. It is the zero-index of the hierarchy: everything branches from it, and nothing in the DNS exists outside it. The root zone is maintained by IANA, the Internet Assigned Numbers Authority, which publishes it openly. The hierarchy is public record all the way down.
The root server does not know where www.example.com lives.