DNS TTL, positive caching, negative caching, and propagation

A DNS change does not spread through one synchronized global process. Authoritative servers publish data, while recursive resolvers and clients cache answers they observed at different times. “Propagation” is usually shorthand for those independent caches expiring and refreshing.

TTL is a cache lifetime, not a delivery deadline

The time to live (TTL) is carried with DNS resource records. A cache reduces the remaining TTL as time passes and should not use the cached record beyond its allowed lifetime under ordinary behavior [2].

If an authoritative RRset has a TTL of 3600 seconds:

• resolver A may cache it one minute before a change;
• resolver B may cache it 50 minutes before the change;
• resolver C may have no cached copy;
• each resolver has a different remaining lifetime at change time.

Resolver C can fetch the new answer immediately. A and B can continue returning the older answer until their own cached copies expire.

Positive caching

A positive response contains the requested data or data used to reach it. Resolvers cache eligible RRsets to reduce latency and authoritative load.

The effective observation window depends on:

• TTL returned when the resolver cached the RRset;
• elapsed time since that observation;
• aliases and referrals with their own TTLs;
• resolver policy, including minimum or maximum cache settings;
• client, operating-system, application, or browser caches; and
• whether the query reached the same DNS view.

The DNS architecture treats caching as a core part of resolution [1].

Lowering TTL before a planned change

Lowering a TTL can shorten later cache lifetimes, but only after caches learn the lower value.

A safe sequence is:

1. lower the relevant TTL at the authoritative service;
2. wait at least the previous TTL before relying on the lower value;
3. verify that every authoritative server publishes the lower TTL;
4. make the planned record change;
5. verify authoritative and selected recursive observations; and
6. restore the normal TTL after the change is stable.

Lowering the TTL seconds before changing the value does not rewrite copies that were already cached with the old, longer TTL.

Negative caching

Resolvers can cache negative answers:

• NXDOMAIN: the queried name does not exist in that DNS context;
• NODATA: the name exists, but the requested type does not.

RFC 2308 defines negative caching and derives the negative cache TTL from the SOA data returned with an authoritative negative response [3].

This creates a common surprise: querying a name before its record exists can cache absence. Adding the record immediately afterward does not force every resolver to discard that negative entry.

SERVFAIL is not the same as an authoritative negative answer. It means the resolver could not complete the request successfully.

Some resolvers can serve stale data

RFC 8767 defines a mechanism for recursive resolvers to use expired data in limited failure conditions to improve resilience [4].

Therefore, an old answer observed after its nominal TTL can reflect documented serve-stale behavior, local policy, or another cache layer. Record the resolver and its response instead of assuming malicious or broken behavior.

Why there is no global percentage

There is no authoritative list of every recursive resolver cache, its users, or the time at which it last queried an RRset. A “90% propagated” claim normally means that a selected monitoring sample saw the new answer. It is not a measurement of the entire DNS.

Current DNS terminology distinguishes authoritative data, resolver caches, and views [5].

Use scoped language:

• “The authoritative servers return the new value.”
• “Resolver X returned the old value at timestamp Y with Z seconds remaining.”
• “Resolver A and resolver B now return the new value.”

Do not say “DNS has fully propagated” without defining the observers and evidence.

A practical change timeline

Assume the old RRset has a 3600-second TTL and the new RRset has a 300-second TTL:

T-3600  Publish TTL 300
T-0000  Confirm all authoritative servers show TTL 300, then change the RRset
T+0000  Cold caches can fetch the new value
T+0300  Caches that learned the reduced TTL should be eligible to refresh

This timeline is a risk model, not a guarantee. Resolver policy, stale serving, client caches, aliases, and missed preflight steps can extend an observation.

Diagnose an old answer

Capture:

1. exact name, class, and type;
2. resolver or authoritative server queried;
3. answer and response code;
4. TTL remaining at observation time;
5. authoritative RRset and TTL from every intended nameserver;
6. aliases or delegations involved; and
7. observation timestamp and network viewpoint.

If authoritative servers disagree, fix publication before blaming caches. If they agree, compare the observed remaining TTL and resolver behavior. If DNS is current but the application is not, investigate CDN, TLS, HTTP, operating-system, or application caches.

Continue the learning path

Review DNS records by purpose or return to the root-to-answer path to place caches in the full resolution sequence.

Then learn how DNSSEC authenticates the chain from parent to child.