TTL and cached answers

Every DNS record has a Time to Live, or TTL. It tells a resolver how many seconds it may cache that answer.

A resolver can reuse the cached answer until that time expires. A full dig answer displays the remaining TTL, not necessarily the original value configured at authority:

dig @1.1.1.1 A flaviocopes.com +noall +answer

Run it again and the number often decreases. When it reaches zero, the resolver must refresh before answering again, although serving stale data in failure conditions is a separate resolver feature.

A short TTL makes planned address changes converge sooner and limits how long mistakes remain cached. It also produces more queries and gives caches less ability to absorb authoritative outages. A long TTL reduces query load and can improve resilience, but extends the transition window.

Lower the TTL before a planned migration. Wait for the previous, longer TTL to expire before assuming every cache has adopted the shorter value.

For example, changing a TTL from 86,400 seconds to 300 seconds five minutes before a move does not help a resolver that cached the old answer an hour ago. It may legally reuse that answer for almost another day.

Aliases have multiple cacheable steps. A CNAME and the target’s A or AAAA records can have different TTLs. Negative answers have their own caching time derived from the zone’s SOA. Diagnose the exact name and record type rather than referring to one universal “domain TTL.”

Compare cache and authority:

dig @1.1.1.1 A flaviocopes.com +noall +answer
authoritative_server=$(dig NS flaviocopes.com +short | head -n 1)
dig @"$authoritative_server" A flaviocopes.com +norecurse +noall +answer

Authority shows the current published value and its original TTL. A recursive resolver may still show an older value with a countdown.

Your action is to record the same answer and TTL from authority and two recursive resolvers three times over several minutes. Explain every difference without using the phrase “DNS propagation.”