DNS Propagation and TTL

DNS propagation is the informal name for the period when different resolvers may return different answers after a DNS change. There is no single global switch. TTL tells caches how long an answer may be reused, but it is not a guaranteed countdown until every user sees the new value.

Why answers differ

A recursive resolver may have cached the old record just before an edit, while another resolver queries the authoritative nameserver afterward. Both can answer differently for a while. Browsers, operating systems, and applications can add their own caching behavior. A nameserver change also affects delegation, so there can be more than one cached layer.

A negative answer can be cached too. If someone checked a hostname before you created its record, their resolver might continue returning the earlier nonexistence answer for a period governed by negative-cache rules.

Plan a safer change

Before a planned migration, check the current TTL and lower it in advance if you control the zone and need a shorter cache interval. Wait for previously cached answers to age out, prepare the new service, and then change the record. Keep the old service running long enough to serve clients using older answers when feasible.

For a nameserver migration, duplicate all necessary records at the new provider before changing delegation. Lowering a record's TTL at the last minute cannot rewrite copies already cached with the old TTL.

Verify the actual state

Compare the authoritative answer with results from different resolvers and note query times. /whois shows a DNS view, but it is not a global propagation checker and cannot prove what every user sees. If the authoritative answer is wrong, fix the zone; if only some resolvers differ, investigate cache timing. Avoid repeated edits that make the timeline harder to understand.

The nameserver guide helps distinguish delegation from individual records.

Sources

• RFC 1034: distributed DNS and caching
• RFC 2308: caching negative answers