Skip to content
WebsiteHosting.com

concept Domains & DNS

DNS TTL

A DNS answer can outlive a change at its source. Follow one resolver cache—not a global propagation clock.

Sources checked · P0003

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

Choose the initial TTL, when the authoritative answer changes, and the time of one later query. Compare the answer at the source with the answer this resolver would return.

Simulation

One resolver. Virtual time. No DNS lookup.

At the authoritative source
New answerAt t = 30 s
This resolver would return
Old answerCache hit · 30 s left
Authority change20 s · short dashesCache lifetime ends60 s · long dashesSelected query30 s · solid line
Initial fill at 0 s; timeline ends at 120 s. Each selection replays a single later query—no hidden intermediate lookups.
Cache timeline inputs
0–120 seconds
0–120 seconds
0–120 seconds

Change the query time to inspect expiration.

The answers differ. The saved old answer is still valid in this cache for 30 s.

About this model

One record cached at t=0; no further queries until the selected time. Authority changes before a query at the same timestamp. A query at or after expiry fetches the current answer; expiry alone does not trigger a lookup. TTL=0 prevents reuse. A change at t=0 makes the initial answer new. No prefetch, eviction, other cache layers, delay, errors or serve-stale policy. Displayed times are rounded to two decimal places; positive times below 0.01 are shown as less than 0.01. This is not global DNS propagation.

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

Sources & model boundaries

Primary references used for this explanation. The interactive example is our own implementation.

  1. RFC 1034 — Domain concepts and facilities

    Sections 3.6 and 4.3.4. TTL in seconds and caching to avoid repeated lookups.

    Checked .

  2. RFC 1035 — Domain implementation and specification

    Section 3.2.1, read with RFC 8767 section 4. Resource records and zero-TTL non-caching behavior; later TTL definition amendments apply.

    Checked .

  3. RFC 8767 — Serving stale DNS data

    Sections 4–6. Amended TTL definition and the serve-stale exception when refresh fails.

    Checked .