DNS caching is not one clock

One laptop reaches the new address. Another still reaches the old one. It is tempting to describe this as DNS “propagating,” as if a single update were moving steadily across the internet. A more useful model is a set of independent caches, each with its own history.

Start with separate clocks

An authoritative DNS service publishes records. A recursive resolver looks up answers on behalf of clients and can keep them for reuse. The operating system, browser, or application may also retain answers. Not every request passes through every layer.

A record’s time to live, or TTL, gives a caching resolver a reuse interval. If a resolver cached an answer with a TTL of 3,600 seconds shortly before a change, lowering the published TTL afterward does not shorten that existing copy’s original interval.

In a conventional cache, the TTL shown in a reply decreases as the cached answer ages. It is not a countdown to a global switchover. Resolvers can impose cache limits, refresh answers early, or serve stale data under certain conditions; applications can also keep connections open after a DNS answer changes.

The practical consequence: a low TTL helps with a planned change only after previously cached, longer-lived answers have had time to expire. Even then, DNS expiry is not proof that every client has moved.

A missing answer can be cached, too

A lookup made before a name exists may return NXDOMAIN. A name that exists but lacks the requested record type can produce a no-data response instead. Both kinds of negative answer can be cached.

For normal negative caching, the lifetime is derived from the zone’s SOA record: the smaller of the SOA record’s TTL and its MINIMUM field, subject to resolver policy. Creating a record does not immediately erase those earlier negative answers.

This is why “I just created it” is important context. Distinguish an old positive answer, an old negative answer, and a lookup failure before treating them as the same problem.

Compare answers before clearing caches

Capture the exact name, record type, resolver, answer, and time of observation. A screenshot of a browser error alone cannot tell you which DNS layer was involved.

If dig is available, these read-only queries illustrate the comparison. example.org is a documentation example; replace it with a name you are authorized to inspect. The second command uses a shell variable you must set to that zone’s actual authoritative nameserver.

# Ask the resolver configured for this environment.
dig example.org A +noall +answer +authority +comments

# AUTH_NS must name an authoritative server for the zone.
dig @"$AUTH_NS" example.org A +norecurse

Check the authoritative answer. Query the zone’s authoritative nameservers and confirm they agree. For an authoritative response, look for the aa flag. A direct query is not evidence of what a client’s resolver has cached.
Compare the recursive answer. Note the response status, returned address, and remaining TTL. Different recursive resolvers can legitimately hold answers obtained at different times.
Check the complete path. Inspect A and AAAA separately. A CNAME adds another name to resolve, with its own cached records. One correct IPv4 answer does not establish that IPv6 or an alias target is correct.
Then inspect the application. A browser may use its own secure DNS resolver rather than the one dig queried. Existing connections and application-level caching can also explain a mismatch.

Clearing a local cache can test a hypothesis, but it also removes evidence. Record the old answer first. A SERVFAIL or timeout deserves a different investigation—such as delegation, DNSSEC validation, or reachability—not an automatic instruction to wait for a TTL.

Plan for an overlap, not an instant

For a controlled migration, reduce the TTL in advance and allow the previous lifetime to elapse before changing the destination. Check that authoritative answers are consistent, then observe the recursive and application paths that matter to your users.

Where feasible, keep both destinations able to handle traffic during the overlap. Restoring the old record is another DNS change, not an immediate undo. A rollback plan needs to account for caches that now hold the new answer.

The useful question is not “Has DNS finished?” It is “Which layer returned this answer, when was it learned, and what evidence would show that this client is using the new destination?”