DNS TTL Explained: Caching, Propagation and Best Practices
DNS TTL, or Time to Live, tells recursive resolvers how long an answer may remain cached. It balances lookup efficiency against how quickly future changes become visible.
How TTL caching works
An authoritative server publishes a TTL with each record. A recursive resolver stores the answer and counts that value down. Repeated users of the same resolver receive the cached answer until the timer expires.
A value shown by dig against a recursive resolver is often the remaining TTL, not necessarily the original authoritative TTL.
dig @ns1.example.net example.com A +norecurse
dig @1.1.1.1 example.com A
sleep 10
dig @1.1.1.1 example.com ATypical TTL choices
- 300 seconds: useful during a controlled migration, with higher query load.
- 1800 to 3600 seconds: a common balance for ordinary service records.
- 14400 seconds or more: efficient for stable records that rarely change.
- NS and delegation TTLs: require more planning because parent-zone caching is involved.
Plan a change correctly
Lower the TTL before the maintenance window and wait at least the previous TTL duration. After that wait, most refreshed caches will hold the shorter value, allowing the actual change to move faster.
dig @ns1.example.net example.com A +noall +answer
dig @ns1.example.net example.com SOA +noall +answerCommon mistakes
Lowering TTL moments before migration
Existing caches can retain the previous long TTL.
Leaving very low TTL permanently
It increases resolver and authoritative query volume without always improving reliability.
Expecting identical displayed TTLs
Resolvers cached the record at different times, so remaining values differ.
Ignoring negative caching
Missing names can be cached according to SOA negative-cache settings.