DNS - the cache that runs the internet

Why this design

DNS is the oldest large distributed cache in production and the one every system on every other board quietly depends on. "What happens when you type a URL" interviews start here, and so do a surprising number of real outages: a record changed with a long TTL still in force, a provider down, a resolver timing out. The useful mental model is not the tree of root, TLD and authority - it is that the tree is almost never walked, because caches at every layer answer first, and every one of them is governed by a number chosen by someone else.

What you will learn

• The full resolution path - browser, OS stub, recursive resolver, root, TLD, authority - and why a warm resolver skips most of it.
• Why a resolver answers 85% of queries from cache, and what sizes its cache (about 5 GB for an ISP of four million homes).
• How the TTL sets both the load on the authoritative servers and the lifetime of a mistake, and why lowering it must happen one old-TTL in advance.
• Negative caching: why a typo'd record that briefly did not exist can keep failing after it is fixed.
• Why authoritative DNS is a single point of failure for everything behind it, and what two providers buys.

How to read this board

1. Press Play: the walkthrough resolves shop.example cold, then warm, then follows a record change and shows where the old answer keeps living.
2. THE ASKER (top left) holds two caches on one machine; THE ADDRESS (bottom left) is the old and new load balancer.
3. THE RECURSIVE RESOLVER (middle) is the cache that runs the internet; THE AUTHORITY (right) is where the record is edited.
4. 1 · Requirements, 2 · Capacity, 3 · Storage - from the point of view of both a domain owner and a resolver operator.
5. 4 · Availability and 5 · How it works, then 6 · Deployment - the TTL-lowering ritual for a migration.
6. Finally the DATA MODEL, then argue with the weakness: a one-day TTL on the record being migrated, and one provider.

Ask these before drawing anything

• Whose side are we designing - the domain owner's authoritative DNS, or a resolver operator's recursive service? They have opposite load profiles and the board shows both.
• How quickly must an address change take effect? That number IS the TTL, and its cost is load on the authority and a cold lookup for more users.
• Is DNS used for failover? Then the TTL is the failover time, plus whatever the slowest client adds.
• How many providers serve the zone? One provider is one failure domain for every service under the name.
• Is the zone signed (DNSSEC)? Signing adds key rollovers, larger responses and a new way to make the whole zone fail validation.
• Do clients honour TTLs? Browsers keep their own short cache; some runtimes and corporate resolvers clamp or extend TTLs regardless of what was published.

Functional

• Resolve a name and type (A, AAAA, CNAME, MX, TXT) to its records, recursively, on behalf of a client.
• Cache positive answers for their TTL and negative answers (NXDOMAIN, NODATA) for the zone's SOA minimum.
• Serve authoritative answers for owned zones from every anycast point of presence.
• Publish a record change to every authoritative PoP within seconds and bump the zone serial.
• Keep an audit of every record change with its previous value and TTL.

Non-functional

• Resolver: cached answer p99 under 2 ms; cold resolution p95 under 150 ms.
• Authority: 100% availability is the honest target, because a failed answer fails every service under the name.
• Zone change visible on every authoritative PoP: p99 under 30 s. Visible to the world: up to the old TTL, by definition.

Out of scope

• DNSSEC key management (a board of its own).
• GeoDNS and latency-based routing - real, and a layer on top of the same caching.
• Encrypted transports (DoH, DoT) - they change who sees the queries, not how caching works.