DNS TTL and caching after a record change
You change a DNS record, but your computer still reaches the old address while another resolver returns the new one. Calling this a propagation delay does not explain where the old answer remains. Follow the cached answer and its remaining lifetime to make the difference easier to diagnose.
TTL describes reuse of an answer
Time to Live is measured in seconds. A recursive resolver caches received DNS data and normally reuses it within its remaining TTL. Changing the authoritative record does not send a worldwide instruction to erase existing caches. A resolver may also discard data early, so TTL does not guarantee that an answer will remain stored for that entire period.
A 300-second example
This simplified timeline shows why TTL is not a fixed countdown starting when you edit a record. RFC 9499 §5 defines TTL.
| Time | Event |
|---|---|
| 10:00 | Resolver A receives the old A record with TTL 300 |
| 10:02 | The authoritative A record changes |
| 10:03 | Resolver A may still return the old address with about 120 seconds remaining |
| 10:05 onward | A fresh lookup is normally needed; refresh failures are discussed below |
Lowering TTL does not shorten copies already cached
If you change TTL from 3600 to 300, a resolver that just fetched the old record still has the original lifetime. To prepare a migration, lower the TTL ahead of the address change and allow for data cached with the previous value. Lowering it at the moment of the switch does not revise those older copies.
A local cache flush has a limited reach
Clearing the DNS cache on a computer does not clear its recursive resolver. The next query may retrieve the old answer again. Browsers and applications may also resolve names independently or reuse existing connections. Different visitors use different resolvers, so TTL alone cannot promise a universal migration completion time.
An answer saying “not found” can be cached too
A newly created name may remain unavailable because an earlier NXDOMAIN answer is cached. NXDOMAIN means the name does not exist; NODATA means the name exists but has no data of the requested type. An empty-looking result is not enough to tell these apart.
Its lifetime is separate from the new A record
RFC 2308 §3–5 derives the negative-answer SOA TTL from the smaller of the SOA record TTL and its MINIMUM field. Values of 3600 and 600 therefore start with a 600-second limit. Setting a new A record to TTL 60 does not change an earlier cached absence to 60 seconds.
Stale answers and failed lookups need different explanations
A supporting resolver may serve expired data when it cannot refresh from authoritative servers. This is serve-stale: RFC 8767 §5–7 describes a method that balances availability and freshness. A normal TTL is therefore not an absolute guarantee that old data disappears in every failure scenario.
SERVFAIL does not mean that a name is absent
Timeouts or DNSSEC validation failures do not establish nonexistence. RFC 9520 §3.2 also requires caching of resolution failures. Immediately retrying after a repair can still encounter a short-lived cached failure.
Use DNS comparison for a specific observation
The Online Tools DNS lookup compares answers from Google Public DNS, Cloudflare, Quad9 and OpenDNS. Enter a public domain and select a record type such as A. The name is sent to the server, which queries those resolvers; private internal names are not suitable inputs.
Agreement is not proof of worldwide completion
These are observations from one place at one time. The tool compares returned values and their majority; it does not display remaining TTL, SOA details or the distinction between NXDOMAIN and NODATA. Differences can also arise from geographic answers or configuration differences. For TTL and negative-answer details, inspect full dig responses in your own environment and compare authoritative answers with those of the resolver you actually use.
Specifications and the resolution path
RFC 1034 §4.3.4: caching; RFC 2308 §5: negative answers; RFC 8767 §4: updated TTL treatment; RFC 9520 §3: resolution failures. Read DNS basics and root servers for the query path, or HTTP caching for a separate cache layer.