The countdown starts the moment you get the answer
The countdown starts the moment you get the answer
TTL is not how long a record is valid — it is how long somebody else may keep serving the old one.
What the field actually encodes
Every DNS record carries a 32-bit unsigned integer in its wire format: the Time To Live. Operators often read it as a freshness stamp — "this record is good for this many seconds" — but that reading puts the obligation in the wrong place. The TTL is a permission grant, and it runs in the direction you might not expect. It tells the resolver, not the zone owner, how long it may continue to answer from its own cache without going back to ask again.
The DNS protocol specification in RFC 1035 ↗ defines the TTL as the number of seconds a resource record may be cached before it should be considered stale. That "should" matters: the zone owner sets the number, but they have no mechanism to revoke it once a resolver has taken it on board. The moment a response leaves the authoritative server and a resolver writes that record into its cache, the countdown begins — on the resolver's clock, not on anything the zone owner controls.
The distinction sounds academic until you change something. Suppose you update an A record and the old IP stops accepting connections. Every resolver that cached the old answer inside its TTL window will keep serving that IP to its clients. From your perspective the record changed immediately; from those resolvers' perspective, they hold a perfectly valid cached answer they have no obligation to discard. The TTL you set before the change is the only lever you had, and if you did not lower it far enough, far enough in advance, you already gave that permission away.
How the number moves through the chain
When an authoritative server returns a record with a TTL of 3600, that value is copied into the resolver's cache. If a second resolver then queries the first (in a forwarding chain), the second resolver does not receive a fresh 3600: it receives whatever seconds remain. RFC 1035 is explicit that resolvers must decrement the TTL as time passes and must not forward a higher value than they received. A record six hundred seconds into its life arrives at the downstream resolver with a TTL of three thousand.
This decrement behavior means the TTL a client eventually sees reflects the age of the cached answer, not the original intent of the zone. A laptop behind a corporate forwarder, which itself sits behind an ISP resolver, might receive an answer with a TTL of forty seconds — not because the zone owner set forty, but because every layer between them has been holding the record for almost an hour. That client's browser will then flush the entry in forty seconds and re-query, and the cycle starts again.
Negative answers — NXDOMAIN and NODATA responses — also carry a TTL, derived from the SOA record's minimum field and the SOA's own TTL, whichever is lower. That negative TTL is often set shorter than positive record TTLs and rightly so: a name that doesn't exist today might exist tomorrow, and an aggressive negative cache can suppress correct answers for its entire duration just as effectively as a stale positive one.
The practical scope of the permission you're granting
A TTL of 86400 — one day — is not unusual for stable infrastructure. It means every resolver that has ever queried that record in the past twenty-four hours may legitimately answer from cache for up to another twenty-four hours after you change it. The maximum propagation delay for a change is therefore not how quickly your secondaries pull a new zone (which for a properly incremented SOA serial is a matter of minutes) but how long the old TTL value takes to run out in the resolver population. The two are completely independent, and conflating them is behind most "why hasn't my change propagated?" puzzles.
The IETF specification in RFC 8767 ↗ addresses what resolvers should do with stale cache data when an authoritative server is unreachable — effectively extending the TTL as an availability measure. This is a separate question from normal TTL expiry, but it underlines the same structural point: the zone owner does not unilaterally control how long their data lives in the network. The resolver's behavior, and increasingly its configuration around stale-while-revalidate policies, shapes the effective lifetime independently.
Setting a very low TTL — say, 60 seconds — reduces the propagation window but increases the query load on your authoritative servers and on the resolver population generally. Every resolver that is actively serving names under your zone will hit your authoritative servers roughly once per TTL per name. At low TTLs with high query volume, this matters. The tradeoff is real: availability during a change versus load during steady state.
This is a separate question from normal TTL expiry, but it underlines the same structural point: the zone owner does not unilaterally control how long their data lives in the network.
The canonical preparation for any migration is to lower the TTL before you move anything — ideally a day before, so that every cache that held the old high TTL has had time to expire it and pick up the new low value. Only then does a change propagate in the reduced window you intended.
What zone owners can and cannot do
Once a resolver has cached a record, the zone owner has no in-band mechanism to push an update, revoke the cached copy, or signal urgency. There is no cache-invalidation message in the DNS protocol. The only tool is the TTL that was set before the record left the server, and the only leverage left after a change has gone out is to wait.
What zone owners can do is build TTL strategy into their operations before incidents occur. Records that never move — DMARC policies anchored to stable infrastructure, MX records for a mail platform with no planned migration — can reasonably carry high TTLs and the low query overhead that comes with them. Records that front load balancers, CDN origins, or anything subject to failover benefit from TTLs short enough that the cache population turns over in minutes rather than hours.
The TTL field is, in the end, a contract written entirely in advance and honored by parties you have no direct relationship with. The resolver at the ISP, the forwarder in the corporate network, the minimal stub on the laptop — none of them have agreed to anything except the number you put in the record. Set it knowing most of them will honour it as written, though some may keep serving the answer for longer than it says.
Setting a very low TTL — say, 60 seconds — reduces the propagation window but increases the query load on your authoritative servers and on the resolver population generally.