DNS TTL

What it means

DNS TTL, or time to live, tells a resolver how long it may reuse a DNS record before consulting its source again under normal caching behavior. The unit is seconds. A cached answer can therefore remain usable even after an authoritative record changes. Caching reduces repeated lookups; it is not a broadcast mechanism. DNS caching

Try it

Simulation — replay one later DNS question. Choose a timing preset or edit the three times. The model starts with one cached answer at time zero and asks what a single query at the selected time would receive. Moving the time control does not secretly perform intermediate queries.

With TTL 60 seconds and an authoritative change at 20 seconds, a query at 30 seconds still uses the old saved answer and has 30 seconds of its original lifetime left. Compare the before-expiry, exact-expiry and after-expiry presets. At exactly 60 seconds, the original entry is no longer reusable and a fresh lookup can obtain the new value. Cache lifetime

“Remaining lifetime” describes the original saved entry in this replay; after its expiry the display does not start a second hidden countdown. Lowering a newly served TTL cannot shorten a lifetime another resolver already saved. Reset restores 60/20/30 and clears invalid input. Times are limited to 0–120 seconds for the scene, not as a DNS protocol limit.

This model excludes eviction, prefetch, multiple resolvers and serve-stale behavior. Those exclusions are why its exact timeline is useful for learning but cannot establish when every visitor will see a real change. Serve-stale extension

One saved answer, one clock

In this simulation the resolver obtains an answer at t = 0. No further query occurs until the selected time. Moving the time control replays that same scenario; it does not secretly refresh the cache on the way.

With TTL 60 s and an authoritative change at 20 s, a query at 30 s still uses the saved old answer. It has 30 s remaining. At 60 s the saved answer is no longer reusable in this model, so a successful lookup returns the new answer. Expiration does not itself send a query: a query at 90 s would trigger the lookup at 90 s, not retroactively at 60 s.

Expiration is not propagation

A TTL belongs to the cached information. A different resolver may have obtained its answer at a different time, so its remaining lifetime can differ. Changing the record's TTL now does not rewrite a lifetime already stored elsewhere. For a planned change, a lower TTL must have been obtained by a cache before it can affect that cache's behavior. Caching and TTL

In practice

Use this scene to reason about one saved answer, not to promise when every visitor will see a change. The displayed TTL always sets the initial answer's lifetime; editing that control starts a different scenario rather than pushing a change into a running cache.

A zero TTL means the answer can be used for the current transaction but is not cached for reuse. Here a query at any selected time consults the source when TTL is zero. When the change time is also zero, the source changes before the initial lookup, so the initial answer is already new. Resource record TTL

About the boundary

This is one resolver, one record and an available authoritative source, with no later queries before the selected one. It excludes prefetch, early eviction, other cache layers, lookup delay and failures. Real resolvers can be configured to serve stale data when refresh fails under the conditions described in RFC 8767. Therefore, “TTL elapsed” is not an unconditional guarantee that no old answer can ever be served. Serve-stale behavior

Key takeaways

A TTL is a lifetime attached to cached data, not a worldwide publication timer. Check the authoritative answer and the resolver answer separately. Before a planned change, allow for the previous lifetime; after a change, verify the same name and type instead of assuming every disagreement is “propagation.”