DNS Resolution

A URL names a host in words (www.example.com), but packets need a 32-bit IP address. DNS is the lookup that bridges the two. It is a distributed, hierarchical database - no single server knows every name, so a lookup walks down the hierarchy from the root until it finds the server that is authoritative for the name.

Type a domain and step through the lookup. Toggle the cache to see the fast path:

current hopresolved

resolver has it cached

1. Stub resolver → Recursive resolverA? www.example.comnot cached - must recurse
2. Recursive resolver → Root (.)A? www.example.comreferral to the TLD server
3. Recursive resolver → TLD (.com)A? www.example.comreferral to the authoritative server
4. Recursive resolver → Authoritative (www.example.com)A? www.example.comthe A record (the answer)
5. Recursive resolver → Stub resolverA? www.example.comA record for www.example.com (now cached)

Click "Next hop" to begin the resolution.

hop 0 / 5

Who does the work

• Stub resolver - the tiny client in your OS. It does not recurse; it just asks a recursive resolver and waits for the final answer.
• Recursive resolver - usually run by your ISP or a public provider (8.8.8.8, 1.1.1.1). It does the actual walking and caches results.
• Root, TLD, and authoritative servers - the hierarchy the resolver walks.

The walk (cache miss)

1. Stub asks the recursive resolver for A? www.example.com.
2. Resolver asks a root server. Root does not know the answer but knows who handles .com, so it returns a referral to the TLD servers.
3. Resolver asks the .com TLD server. It returns a referral to the servers authoritative for example.com.
4. Resolver asks the authoritative server, which returns the actual A record.
5. Resolver caches the answer and hands it back to the stub.

Why caching matters

That walk is several round trips. The recursive resolver caches every answer for the record's TTL, so the next lookup for the same name - the "cached" toggle above - collapses to a single hop. Caching is what keeps DNS fast despite the hierarchy.

Worked example: a TTL timeline

Say www.example.com has an A record with TTL=300 (5 minutes), and the first lookup happens at t=0s:

• t=0s - cache miss. The full walk (stub -> resolver -> root -> TLD -> authoritative) runs, costing several round trips, and the resolver stores the answer with an expiry of t=300s.
• t=45s - another client behind the same resolver asks for the same name. Cache hit: one round trip (stub to resolver), answer returned immediately.
• t=299s - still a cache hit, one second before expiry, same as above.
• t=301s - the cached entry has expired. This lookup is a cache miss again and pays the full multi-hop walk, exactly like t=0s.

A shorter TTL (say 30s) means changes propagate faster when you update a record, at the cost of paying the full walk far more often; a longer TTL (say 86400s / 1 day) is cheaper and faster on average but means a bad record stays wrong, cached everywhere, for a full day after you fix it.

⚠Cached DNS masked - then amplified - the 2021 Facebook outage

On October 4, 2021, Facebook's own network withdrew the BGP routes to its authoritative DNS servers during a botched maintenance change, making those servers completely unreachable from the outside Internet. Resolvers around the world that already had Facebook's records cached kept serving them correctly until each cached record's TTL expired - so the outage did not hit everyone instantly. But as TTLs expired at different times, each resolver in turn found it could no longer reach any authoritative server to refresh the record, and started returning failures. The incident is a concrete illustration of two things at once: TTL caching genuinely buys resilience against a short outage, but it cannot help once the authoritative servers are unreachable for longer than the TTL - eventually every cache empties out and the failure becomes total and visible everywhere.