Resolution · stage 02
TTL and staleness
A cached answer has a lifetime, and when you change a DNS record the old answer keeps circulating until every cache has let it go.
Stage 02 of six/Resolution, piece 2 of 3/Full piece/Next: Anycast
What TTL actually governs
Every DNS record carries a Time to Live — a number, measured in seconds, set by whoever manages the zone. When a resolver fetches a record, it stores the answer and starts counting down. Until that counter reaches zero, the resolver hands out its cached copy without asking the authoritative server again. The TTL is not a suggestion; it is the contract between the authority that knows the truth and the resolvers that distribute it.
The figure lives in the record itself — not in the connection, not in any HTTP header. A value of 300 means resolvers should hold the answer for five minutes. A value of 86400 means a full day. Operators set these figures, and the consequences land on them: too short and you hammer your authoritative servers with constant queries; too long and a change you make today might not reach a user's resolver until tomorrow.
What the TTL does not govern is the depth of the caching chain. Between a user's device and an authoritative nameserver there are usually at least two caches: the stub resolver embedded in the operating system, and the recursive resolver operated by an ISP or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Each cache obeys the TTL independently. The recursive resolver's cached copy might expire hours before the OS cache does, or vice versa, depending on when each one first fetched the record.
There is also the question of floors. The DNS hierarchy gives resolvers some latitude; some public resolvers enforce a minimum TTL regardless of what the zone says, rounding a value of 30 seconds up to 300 or more, on the grounds that very short TTLs generate excessive traffic. The IETF's work on DNS (principally in RFC 1034 and RFC 1035, the documents that defined the system) leaves enforcement of the stated TTL to implementers, which is one reason behaviour varies.
Why changes are slow to propagate
When you update a DNS record — pointing a domain at a new server, swapping an IP address after a migration, adding a new subdomain — the authoritative server answers with the new value instantly. The problem is that no one is asking. Every resolver that fetched the old value before your change is sitting on a cached copy that is still valid according to its own counter. The new answer exists at the top of the hierarchy, but it takes time to filter down.
This is the phenomenon called propagation, though that word oversells the mechanism. Nothing is pushed. The new record does not travel outward from your nameserver; it simply waits. Resolvers come to it only when their cache entries expire. The practical result is a window during which some users see the old address and others see the new one, depending entirely on when their resolver last asked the question and what TTL was in effect at that moment.
The standard mitigation is to lower the TTL well before a planned change — sometimes to 300 seconds or less — and wait for that shorter value to propagate and be cached. Then make the change. The maximum time any resolver can be out of date is now the lower value. The technique works because TTL changes propagate on exactly the same schedule as any other record change: after the old TTL expires, resolvers fetch the updated record, which now includes the new (lower) TTL.
None of this is failure. The caching behaviour that causes propagation delay is also what makes the DNS fast and scalable at global scale — the same efficiency that lets anycast routing distribute query load across continents without every resolver reaching back to a single origin for every lookup. Staleness is the price of that design, and the TTL is the knob that lets operators calibrate how much of it they are willing to tolerate.
The new record does not travel outward from your nameserver; it simply waits.
