DNS Time to Live (TTL): Why Changes Take Time to Show Up

Every DNS record on a domain carries a TTL -- time to live -- expressed in seconds. It's an instruction from the domain's authoritative nameserver to every resolver that fetches the record: "you may reuse this answer for this long before asking again." A 300-second TTL means a resolver that just looked up a domain won't bother asking again for five minutes, even if the record changes in the meantime.

The tradeoff TTL is balancing

A longer TTL means fewer DNS queries, faster average lookups (since more requests get served from cache), and less load on the authoritative nameservers. A shorter TTL means a change to the record propagates faster, at the cost of more frequent queries. There's no universally correct value -- it depends on how often the record is expected to change and how tolerant the situation is of stale answers.

What actually happens during a change

Updating a DNS record doesn't push the change out to every resolver on the internet. It just changes what the authoritative nameserver will say the next time it's asked. Every resolver that already cached the old answer keeps serving it until its cached copy's TTL expires -- which is why the same domain can briefly resolve to different addresses depending on which resolver, and which cache, is answering.

• A common practical move before a planned migration is to lower the TTL a day or two ahead of time, so the eventual cutover propagates faster.
• After the migration, the TTL is typically raised back to its normal value.
• A record with no recent changes and a long TTL can still take that full TTL window to fully clear out of caches worldwide once it does change.

Picking a TTL in practice

Negative answers get cached too, which is easy to overlook. When a domain doesn't exist, the NXDOMAIN response itself is cached, governed by a separate value (the SOA record's minimum TTL, not the TTL of a record that was never there to begin with). A newly registered domain can sometimes appear not to resolve for a short window afterward simply because a resolver had already cached its NXDOMAIN from before the registration completed.

TTL is a request, not a guarantee

It's worth knowing that a TTL is advisory, not enforced by any outside authority. A resolver is technically free to cache an answer for longer than the stated TTL (some do, under heavy load, to reduce query volume) or to evict it sooner (a resolver low on memory can drop cache entries early). In the overwhelming majority of cases, well-run public and ISP resolvers honor TTLs closely and predictably -- but it's the reason a propagation estimate based on TTL is a strong rule of thumb rather than a hard, contractual guarantee. If a change still hasn't shown up meaningfully past the old TTL window, an unusually aggressive intermediate cache is one of the less common but real explanations worth keeping in mind.

If you're verifying that a DNS change has gone live, a single lookup only tells you what one resolver currently has cached. Re-running the lookup a few minutes apart -- or scheduling a recurring check -- is a much more reliable way to confirm a change has actually propagated rather than catching a stale cached answer once and assuming it's final.