TTL lowering: the universal pre-flight
The rule in 50 words: lower TTL, wait at least one current TTL, change the value, verify, restore. The wait is what makes it work.
Every planned DNS change benefits from the TTL drop. The drop is cheap (one edit), the benefit is concrete (the change goes from user-visible for up to 24 hours to user-visible within 5 minutes), and the discipline is one most techs eventually internalise.
The rule:
Lower TTL → wait at least one current TTL → make the change → verify → restore TTL.
Why the wait matters
sequenceDiagram
autonumber
participant Auth as Authoritative server
participant Resolver
Note over Auth: Today: lower TTL to 300
Resolver->>Auth: query
Note over Resolver: still holds old answer at old TTL (e.g. 86400)
Note over Resolver: 24 hours pass, cache expires
Resolver->>Auth: re-query
Auth-->>Resolver: now caches at TTL 300
Note over Auth: Tomorrow: change the value
Resolver->>Auth: query (after at most 300 seconds)
Auth-->>Resolver: new value
Downstream resolvers continue serving the old TTL until their existing cache expires. The wait between lower TTL and change value lets resolvers re-query and pick up the new (lower) TTL. Skip the wait and the drop didn’t actually propagate; the value change still takes the old TTL’s worth of time to settle.
Picking the right reduced TTL
| Value | When |
|---|---|
| 60 sec | Below most resolver floors; overkill, adds authoritative-server load. |
| 300 sec (5 min) | Standard cutover TTL. Works for almost all migrations. |
| 600 sec (10 min) | Slightly more cushion, slightly less load. |
Don’t go below 60. Resolvers may not honour TTLs that low; you add load without proportional benefit.
Picking the right restored TTL
After the change has settled (an hour with no issues), restore based on how often the record actually changes:
| Value | When |
|---|---|
| 3600 (1 hour) | Common operational default; most records that change occasionally. |
| 86400 (24 hours) | Stable records (MX of a long-stable provider, SOA, NS). |
| 300-600 | Records that may change frequently (DNS-based load balancing, geo-routing). |
Leaving everything at 300 indefinitely isn’t wrong, but it’s noisier than necessary and slightly slower for client lookups (lower cache hit rates downstream).
What this is NOT
- “Lower TTL on the same edit as the value change.” Doesn’t help. The downstream caches’ current TTLs control the wait, not the new TTL.
- “Lower TTL 30 minutes before a cutover when the previous TTL is 86400.” Barely better than not lowering. The previous TTL is the wait you need.
- “Leave everything at 300 indefinitely.” Works but slowly degrades the resolver cache hit rate worldwide. Cosmetic but worth tidying.
When to escalate
- The previous TTL is exceptionally high (apex SOA / NS sometimes 604800 or more) and the cutover timeline doesn’t allow the full wait. Senior decides whether to proceed without full TTL discipline.
- The TTL drop is on records the client considers ultra-critical (financial-services mail, real-time trading, payment processing). Senior owns the cutover plan.
- You’re unsure which records will change in an upcoming cutover. Senior knows the bigger picture.