DNS Propagation, TTL and Cached Missing Records

Compare the exact DNS question and its cached answer before treating a recent change as complete or broken.

Ask the same question

Use Compare resolvers for the same full name and record type. A and AAAA are separate questions. Matching Google and Cloudflare observations do not establish that every device or recursive cache has refreshed.

What the remaining TTL means

A resolver’s returned TTL is the remaining lifetime of that cached observation. Lowering an authoritative TTL does not retroactively shorten an answer another resolver already cached. For example, a resolver that previously cached a record for an hour may still use that older lifetime after the authoritative value changes.

Missing answers can be cached too

NXDOMAIN reports a name-resolution failure; a successful response without the requested type is a different outcome. Negative caching can retain either kind of absence under the protocol’s rules. Where an appropriate SOA is supplied, its TTL and minimum field determine the negative-cache lifetime. Neither is a universal migration completion countdown.

After publishing a new name

If one resolver previously saw the name as absent, a later positive authoritative answer does not instantly remove that cached negative result. Compare timestamps and response codes. Recheck deliberately; repeated queries do not flush all caches. Do not append random labels to the intended name and treat that as the same question.

When public DNS agrees but the application fails

Use DNS Lookup to inspect aliases and both address families, then examine the resolver actually used by the failing client. Public DoH does not test corporate split DNS. HTTP redirects, TLS configuration and application caches can still send the user to an old service after DNS changes. The dig reference provides local diagnostic commands.

Sources