Definition
The number of seconds a DNS record may be cached before it must be treated as expired. TTL choices affect change speed, query load, resilience, and negative or stale-answer behavior.
Plan a cache-aware DNS change
Synthetic timeline: a resolver cached app.example. at 09:00 with TTL 3600. Lowering the authoritative TTL at 09:10 does not shorten that cached hour.
Before migration, reduce the authoritative TTL from 3600 to 300 and allow the old cache lifetime to elapse.
Check dig @<lab-resolver> app.example. A +noall +answer: app.example. 180 IN A 192.0.2.10 means this displayed answer has 180 seconds of TTL remaining.
Compare dig @<lab-authority> app.example. A +norecurse with the intended new address, such as documentation address 192.0.2.20.
After cutover, check several relevant resolvers and clients. Configured serve-stale behavior may retain expired data when authoritative refresh fails.
What this does not mean
- TTL is a guaranteed global propagation deadline.
- TTL controls cache reuse and refresh. It does not synchronize all caches, clear application caches, or override RFC 8767 serve-stale behavior.
- An expired cached record is deleted from the authoritative zone.
- Cache expiry triggers source consultation. The authoritative record remains until its zone data changes.
A practical review order
- Record the pre-change TTL, change time and expected cache-expiry window.
- Inspect authoritative availability and resolver serve-stale policy when old answers persist.
- Treat negative caching separately; the SOA in a negative response informs its cache lifetime.