Domains & DNS
DNS TTL planning: choose cache times before a change or migration
DNS TTL planning controls how long recursive resolvers may reuse an answer before asking again. TTL is not a universal propagation timer and it does not guarantee every cache disappears at the same instant. Plan it around change risk, resolver load, and how quickly rollback must become visible.
Start with the current authoritative TTL
Inspect the exact A, AAAA, CNAME, MX, or other record that will change and record its current TTL before editing. A lower TTL only helps after existing caches containing the old higher TTL have naturally expired.
For a planned migration, lower the TTL far enough in advance that the previous value no longer controls most recursive caches when the cutover begins.
Use different TTLs for different stability needs
Stable infrastructure records can reasonably cache longer than records being actively migrated. Very low TTLs increase query load and do not fix incorrect authoritative data.
Email MX, verification TXT, DKIM keys, and service discovery records may have different change cadence from a website address. Do not reduce the entire zone blindly.
Plan rollback using cache behavior
If the new destination fails and you restore the old record, recursive resolvers may still hold either answer until its TTL expires. Keep both source and destination healthy during the overlap when the service allows it.
For stateful applications, DNS rollback does not synchronize newer database writes back to the old environment.
Restore a normal TTL after the move
Once the destination is stable and old caches have expired, return records to a sensible normal TTL. Keep the migration timestamp, old/new values, and final authoritative answer in the change record.
- Lower TTL before the maintenance window.
- Change only records involved in the move.
- Keep both sides available through cache overlap.
- Raise TTL again after verification.