DNS Resolution: How Root, TLD and Authoritative Servers Find an Address

Turning a name into an address

Every time you type a domain name, something has to translate it into the IP address your computer actually needs to open a connection. The Domain Name System does this through a strict hierarchy: a root zone (13 logically distinct root server clusters, served from hundreds of physical locations via anycast) knows only which servers are authoritative for each top-level domain (.com, .org, .uk); each TLD server knows only which servers are authoritative for the specific second-level domain; and the authoritative server for that domain finally holds the actual A or AAAA record mapping the name to an address. No single server holds the whole map — the system scales precisely because each level only needs to know about the level directly below it.

Recursive vs. iterative resolution

Your device almost never talks to the root, TLD and authoritative servers itself. Instead it asks a recursive resolver — run by your ISP, or a public one like 1.1.1.1 or 8.8.8.8 — to do the whole lookup and hand back a final answer. The resolver does the multi-step work: it asks a root server which TLD server to try, asks that TLD server which authoritative server to try, and asks the authoritative server for the actual record, following referrals at each hop until it reaches an answer instead of another referral.

client -> resolver:      "what is A record for www.example.com?"
resolver -> root:        "who handles .com?"        <- referral
resolver -> .com TLD:    "who handles example.com?"  <- referral
resolver -> example.com: "what is www.example.com?"  <- authoritative ANSWER
resolver -> client:      198.51.100.7 (cache this for `TTL` seconds)

This split matters because it separates two very different jobs. Iterative queries (server hands back either an answer or a referral, never doing further lookups itself) are what root and TLD servers do — they must stay lightweight and stateless to handle enormous global query volume. Recursive resolution (do the whole multi-hop walk and return only a final answer) is what resolvers do on the client's behalf, and it's deliberately kept off root/TLD servers to avoid overloading the busiest, most safety-critical part of the entire system.

Caching and TTL

Every DNS record carries a TTL (time to live, in seconds) set by its owner, and a resolver caches the answer for exactly that long before it's allowed to ask again. This is what makes DNS scale to the size of the internet — repeat queries for popular domains are answered instantly from cache, with zero network round-trips to root or TLD servers, and the vast majority of real-world queries never leave the resolver's cache. Setting TTL is itself a trade-off: a long TTL (hours to days) reduces load and speeds up repeat lookups but makes updates to a record propagate slowly, since cached resolvers keep serving the stale answer until it expires; a short TTL (seconds to minutes) is what services use just before a planned migration or failover, accepting more query traffic in exchange for the ability to redirect clients within minutes.

; example TTL in a zone file (seconds)
www.example.com.  300  IN  A  198.51.100.7
; 300s = 5 minutes: a resolver serves this cached answer to every
; client that asks, for 5 minutes, before it re-queries the authoritative server

Why this design survives attacks and outages

Distributing authority hierarchically also distributes failure. If one authoritative server for a small domain goes down, only queries for that specific domain are affected — root and TLD service for the rest of the internet is untouched. Root servers themselves are heavily replicated via anycast (the same IP address announced from hundreds of physical locations; routers send each query to the topologically nearest instance), so even a large-scale denial-of-service attack against the roots, which has been attempted more than once, tends to only degrade performance in specific regions rather than take the whole system down. Caching compounds this resilience: most queries never even reach the authoritative tier during an outage, because they're served from resolver caches that were populated before the outage began.

Frequently asked questions

Try it live

Everything above runs in your browser — open DNS Resolution and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.