The full path from a domain name to an IP address is only three questions long, and the system is engineered so that it almost never has to ask them.
Every connection begins with a name lookup. The browser has wikipedia.org and needs a number. The Domain Name System, specified in RFC 1034 and RFC 1035 in 1987 and still running on that architecture, answers by walking down a tree. No single server holds the mapping. The root servers know which servers hold .org. The .org servers know which servers hold wikipedia.org. Wikimedia’s own servers hold the address. Each step is a referral, not an answer.
That walk costs three network round trips to three different operators on three different networks. If it ran on every page load, the web would feel noticeably slower than it does. It does not run on every page load, because every record in the tree carries an expiration timer, and the resolver in the middle keeps the answers until they expire.
The walk, measured
The trace below was run on 2026-08-08 from a residential connection using dig +trace, which forces the resolver to skip its cache and ask each level in turn. The times are the round trips reported by dig for each referral.
| Question asked | Answered by | What came back | Round trip |
|---|---|---|---|
Who serves .org? | j.root-servers.net | 6 name servers for .org, TTL 172,800 | 53 ms |
Who serves wikipedia.org? | c0.org.afilias-nst.info | 3 Wikimedia name servers, TTL 3,600 | 49 ms |
| What is the A record? | ns0.wikimedia.org | 208.80.153.224, TTL 180 | 49 ms |
Total: 151 milliseconds and 1,638 bytes of DNS traffic before the browser opens a single TCP connection. The root zone is operated as 13 named server identities, a.root-servers.net through m.root-servers.net, under IANA’s coordination; the trace above happened to land on j. The .org zone is run by Public Interest Registry, whose name servers still carry the afilias-nst hostnames from the registry’s earlier operator. Only the third answer came from Wikimedia itself.
Now the same lookup against a public resolver that has already done the work. Querying Cloudflare’s 1.1.1.1 for a name it had never seen, a randomized subdomain of wikipedia.org, took 51 milliseconds. Querying it for wikipedia.org, which it had cached, took 6 milliseconds. That 8-to-1 gap is the entire economic argument for the resolver layer.
The TTL is the real control surface
Each answer carries a time-to-live in seconds, set by whoever operates the zone. Until the TTL expires, every resolver holding that answer serves it without asking anyone. The number is a deliberate choice, and operators do not choose the same way. These are the TTLs their authoritative servers returned on 2026-08-08.
| Domain | Authoritative operator | A record TTL | Answers served per day from one cache entry |
|---|---|---|---|
github.com | NS1 | 60 s | 1,440 refreshes |
netflix.com | AWS Route 53 | 60 s | 1,440 refreshes |
nytimes.com | NS1 | 120 s | 720 refreshes |
wikipedia.org | Wikimedia | 180 s | 480 refreshes |
cloudflare.com | Cloudflare | 300 s | 288 refreshes |
amazon.com | AWS Route 53 | 900 s | 96 refreshes |
The delegation records above these are set far longer. The root’s referral to .org carried a TTL of 172,800 seconds, or 48 hours. The .org registry’s referral to Wikimedia’s name servers carried 3,600 seconds. The structure is a pyramid of staleness: the parts that almost never change are cached for days, and the part that operators want to move on short notice is cached for a minute.
A 60-second TTL means a resolver that serves 100,000 users asks Route 53 about netflix.com 1,440 times a day. A 900-second TTL cuts that to 96. Amazon accepts a 15-minute delay in redirecting traffic in exchange for a 15-fold reduction in query load. Netflix and GitHub buy the opposite trade: they can pull a broken region out of rotation and have the internet follow within a minute.
What the two tables show together
The three-referral walk is the system’s advertised design, and it is the path a lookup takes roughly once per TTL per resolver, not once per user. The 180-second TTL on wikipedia.org means that a resolver serving a million people performs that 151-millisecond walk 480 times a day and answers every other query from memory in 6 milliseconds. The hierarchy provides correctness and the cache provides speed, and they are separate mechanisms that happen to compose.
This also explains the failure mode people actually experience. When a site moves and users report that it works for some people and not others, nothing is broken. Resolvers are holding an answer that was valid when it was fetched and will be re-fetched when its TTL expires. The spread of the outage across users is exactly the spread of cache expiry times, which is why the fix is always to lower the TTL before the migration, not during it.
The lever is the TTL, and it is set in advance or not at all. Dropping amazon.com from 900 seconds to 60 costs 1,344 extra queries per resolver per day and buys the ability to move traffic in one minute instead of fifteen. Any operator planning a cutover should lower the record to 60 seconds at least one full TTL before the change, so the old 900-second answers have already drained out of the world’s caches by the time the new address goes live. Lowering it on the day of the migration only guarantees that the last set of 15-minute answers is still circulating while the switch is flipped.