DNS TTL and propagation: why changes take time

TTL: a cache timer on every record

RFC 1035 defines the TTL as a 32-bit number giving the time interval, in seconds, that a record may be cached before the source of the information should be consulted again. A value of 0 means the record can only be used for the transaction in progress and should not be cached.

Cloudflare's guide describes caches at several levels: the browser, the operating system's stub resolver and the recursive resolver at your ISP or DNS service. Each holds a copy for at most the TTL it received. A resolver passes on the remaining time, not the original, so a record with TTL 3600 that has sat in a cache for 20 minutes is handed out with about 2,400 seconds left.

Why propagation looks random

Different resolvers cached the old record at different moments, so they expire at different moments. One resolver may have fetched it a second before your change and keep it for the full TTL; another may not have had it cached at all and fetches the new value immediately. Checking from several places at once shows this patchwork, which is what propagation checkers do.

Some differences are not caching at all. Content delivery networks give different addresses depending on where the question comes from, so two regions can disagree permanently, and both answers are correct.

Negative answers are cached too

If you look up a name before creating its record, the resolver gets a negative answer: NXDOMAIN when the name does not exist, or NODATA when the name exists but has no record of that type. RFC 2308 requires negative answers to include the zone's SOA record so they can be cached, and sets their cache time to the smaller of the SOA record's own TTL and its MINIMUM field.

So a test lookup made too early can make a new record look missing for a while after you add it. RFC 2308 suggests resolvers limit negative caching, noting that values of one to three hours work well and values above one day cause problems.

Worked example: moving a website with a short switch

The A record for www.example.com points to 192.0.2.10 with a TTL of 14,400 seconds (4 hours). The site is moving to 198.51.100.20. Changing the address directly would leave some visitors on the old server for up to 4 hours. Lowering the TTL first shortens that to minutes.

Reading a propagation check

When you check a record shortly after a change, a mixed result is expected. What matters is the remaining TTL of the old answers: once the longest of them has run out, every resolver that respects TTLs must ask again. If old answers persist past that point, either the change was not saved on the authoritative servers, or the domain's NS records point somewhere other than where you edited.