DNS
A globally distributed, aggressively cached phone book — and the reason your deploy 'didn't work' for 20 minutes.
25 minDifficulty 2/5networking · infraAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
Why this exists
You update a DNS record pointing `api.example.com` at a new server, and for the next twenty minutes some visitors still hit the old server while others reach the new one — nothing is broken, DNS is simply a globally distributed, AGGRESSIVELY CACHED system, and every layer of that cache has its own opinion about how long your old answer is still valid.
The mental model
DNS is the internet's phone book — translating a human-readable name (`example.com`) into the numeric IP address a computer actually needs to open a connection. But unlike a single phone book, it's a hierarchy of servers, each responsible for a piece of the namespace, and every answer along the way gets cached at multiple layers to avoid re-asking the same question millions of times.
How it works
Resolution walks a hierarchy, from root to the specific domain
Looking up `api.example.com` involves asking a root server 'who handles .com?', then asking that .com server 'who handles example.com?', then asking THAT server for the specific `api` record — each step delegates to a more specific authority, narrowing down until the actual answer is found. In practice, most of this is cached at intermediate resolvers, so the full walk rarely happens for popular domains.
TTL controls how long an answer is cached, at every layer
Every DNS record has a Time To Live — a number of seconds saying how long a resolver may cache this answer before asking again. A record with `TTL: 3600` cached by a resolver at 10:00 will keep being served, UNCHANGED, until 11:00, even if the actual record changes at 10:05 — this is precisely why DNS changes don't propagate instantly.
Caching happens at multiple independent layers, each with its own TTL memory
The browser caches a lookup, the operating system caches it separately, the local network's resolver caches it, and the ISP's resolver caches it too — a single lookup might be served from any of these layers, each of which may hold a DIFFERENT cached snapshot, from a different point in time. This is why 'it works for me but not for my coworker' is such a common DNS symptom right after a change.
Lowering the TTL before a planned change is a real, useful technique
Since a low TTL means caches expire and re-check more frequently, deliberately lowering a record's TTL (say, from an hour to a minute) SEVERAL HOURS before a planned migration ensures that by the time the change happens, most caches have already picked up the shorter TTL and will re-check soon after the actual switch — minimizing the window where stale answers linger.
The mechanism
A resolver with no cached answer walks the hierarchy from the root, being delegated to progressively more specific servers until it reaches the authoritative server for the exact domain in question, which returns the actual record along with a TTL. The resolver caches this answer for that TTL's duration, serving it directly from cache for any repeated lookup within that window rather than repeating the walk.
sequenceDiagram participant C as Client resolver participant R as Root server participant T as .com TLD server participant A as example.com's authoritative server C->>R: who handles .com? R->>C: ask T C->>T: who handles example.com? T->>C: ask A C->>A: what's the IP for api.example.com? A->>C: 203.0.113.5 (TTL: 3600) Note over C: caches this answer for up to 3600 seconds
What people get wrong
- DNS changes take effect for everyone instantly, or within a fixed, universal 'propagation time'.
- There's no single global propagation time — different resolvers around the world cache the OLD answer for however long its TTL says, and each one only re-checks once ITS specific cached copy expires, so different users can see the change at genuinely different times. The term 'propagation' misleadingly suggests an active push of the new value everywhere — what's actually happening is many independent caches passively expiring on their own separate schedules, based on the TTL that was in effect when they last cached the record.
- A DNS record's TTL can be effectively ignored, since resolvers will just get the latest value anyway.
- A resolver strictly honors the cached TTL and will keep serving the old answer for that full duration, even if the actual authoritative record changed moments after it was cached — there's no mechanism to proactively push an update to already-caching resolvers. This is precisely why lowering the TTL in advance of a planned change is a real, necessary technique rather than an unnecessary precaution — without it, a migration can leave some traffic hitting the old server for the record's full original TTL.
- DNS lookups always require a live network round trip.
- Most lookups for frequently-visited domains are served entirely from a cache (browser, OS, or local resolver) with no network round trip to any DNS server at all — the full hierarchical walk only happens on a genuine cache miss. Understanding this explains why DNS lookups are usually imperceptibly fast in practice, despite the theoretical multi-hop hierarchy that would be needed for an uncached lookup.
When not to use it
- You're about to perform a planned migration to a new server IP and want minimal downtime from stale DNS answers.
- Lower the record's TTL well in advance (hours, not minutes) of the actual change, so caches have already adopted the shorter TTL and will re-check soon after the real switch happens.
- You need failover that reacts within seconds to a server going down, faster than any reasonable DNS TTL could provide.
- A load balancer or health-check-based routing layer in front of the servers (see `load-balancing`) — DNS TTLs, even set aggressively low, aren't a substitute for sub-second failover.
Terms
- TTL (Time To Live)
- — The duration, in seconds, that a DNS answer may be cached before a resolver must ask again.
- Authoritative server
- — The DNS server that holds the actual, canonical records for a specific domain, as opposed to a resolver that merely caches and forwards lookups.
- Resolver
- — A DNS server (or client-side component) that performs lookups on behalf of a client, potentially caching results along the way.
- Propagation
- — The informal term for the period during which different caches around the world may still be serving a domain's old DNS answer after a change, until their respective TTLs expire.
In an interview
You changed a DNS A record an hour ago, but some users still reach the old server. Is something broken?
- not necessarily broken — this is expected behaviour given how DNS caching and TTLs work
- different resolvers cached the old answer at different times and will only re-check once their own copy's TTL expires
- if the record's TTL was, say, 4 hours, some caches could correctly serve the old answer for up to 4 hours after the change
Can you recall it?
Why can two different users see different results immediately after a DNS record change, with nothing actually broken?