Test DNS › DNS guides

TTL and the propagation of zone changes

After an address change, it is common to hear that you have to wait for propagation. DNS propagates nothing: it lets copies expire. Understanding this nuance changes the way you prepare a migration and how you read the delays you observe.

Glass hourglass resting on a light wooden table — The TTL is counted in seconds in every cache: the delay you experience depends on the oldest copy.

A lifetime, not a broadcast

Each DNS answer carries a TTL, in seconds, which the authoritative server attaches to the records it returns. The resolver that receives the answer keeps it for that length of time and serves it to every host that asks for it. There is no broadcast from the authority to the resolvers of the world: the change becomes visible as copies expire, each at its own pace.

This distinction is not a subtlety of vocabulary. Speaking of propagation suggests a centralised mechanism and a known delay; speaking of expiry assumes independent caches, with different durations and sometimes specific behaviour. It is this second reading that makes it possible to predict the real effect of a change.

The TTL belongs to the record set, not to the name: two records with the same name but different types can carry different lifetimes. Changing a TTL for one type does nothing for the others, which explains some of the differences in behaviour observed after a partial migration.

Who keeps a copy

The first cache is that of the resolver that made the query, often the one of the access provider or a public resolver. It applies the TTLs supplied by the authority, sometimes with internal limits. The workstation also has its own local cache, fed by that resolver: after a change, clearing this local cache is pointless as long as the upstream resolver still holds the old answer.

Applications, finally, keep their own entries, sometimes well beyond the TTL: a mail client may keep the address of the mail server, a browser may reuse an established connection. These layers explain why a service still appears to reach the old address when the zone is already correct everywhere.

Preparing a change without downtime

The classic method is to lower the TTL of the record concerned before the operation, then wait at least the length of the old TTL. All copies of the old value have then expired, and the change becomes visible almost immediately for everyone. Once the change has settled, the TTL can be raised again.

The frequent mistake is to lower the TTL and make the change within the minute, without waiting: copies of the old value, created before the lowering, keep their original duration. The delay then observed is that of the old TTL, not the new one, and it can run to hours. A permanently very low TTL is not a solution: it multiplies queries to the authority and weakens resolution in the event of an incident.

Negative caching and the role of the SOA

A name that does not exist is cached too. RFC 2308 frames this practice: the duration of the negative cache is derived from the minimum field of the zone's SOA, with ceilings intended to prevent an error from freezing for too long in resolvers. Without these limits, a name created after an unsuccessful attempt would remain unfindable for days.

This behaviour has a direct consequence for deployments: creating the records first, then announcing the name, avoids generating a negative cache entry. Conversely, testing a name before creating it leaves a trace in resolvers, sometimes longer than expected.

When a resolver serves expired data

Expiry is not an absolute guarantee. RFC 8767 describes the serving of stale data: when a resolver cannot reach the authoritative servers, it may answer with an expired copy rather than fail, so as to keep resolution working during an incident. This behaviour is an operational choice, bounded by maximum durations.

For the administrator, this means that a change can remain invisible for longer if the authority is momentarily unreachable. A persistent gap between the published zone and what a resolver returns is therefore not always a cache fault: you have to check access to the authoritative servers before drawing conclusions.

Verify instead of waiting

The useful check is to query the authoritative servers directly, without recursion: the answer they give is the published truth. Then query several distinct resolvers, noting the remaining TTL, to see the state of the caches. A high TTL on an old answer indicates a copy that is still valid, not a fault.

The survey must cover several resolvers, because each one has its own cache. Concluding from a single attempt amounts to drawing a generalisation from a local observation, and it is the most frequent source of false alarms after a zone change.

The TTL is a lifetime applied by each cache, never a centralised dissemination delay.
Lowering a TTL only takes effect once the copies created with the old value have expired.
Negative caching depends on the SOA: it is set before deployment, not after.
A resolver may serve stale data if the authority is unreachable.
The only published truth is that of the authoritative servers, queried without recursion.

References

To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.

← DNSSEC: principles of signing and validation Logging and monitoring a DNS server →