Lower DNS TTL before a migration — a checklist

Drop TTLs days before a CDN or origin cutover, keep mail records stable, then raise TTLs after the new path has been boring.

The most expensive DNS mistake is changing a record that still has yesterday's 24-hour TTL. Lower first, wait, change, watch, then raise.

Inventory the records that must move

Apex, www, API, asset and CDN hostnames. Leave MX and verification TXT alone unless they are actually moving.

If the record was 86400, wait at least a day after you publish the low TTL before you change the target. Otherwise both answers are in the wild.

Point at Cloud CDN or the new origin. Rollback is the same record with the same low TTL. Do not raise TTL in the same change.

Static records can go back up. Failover targets may stay low forever. Cloud DNS can absorb that query volume on Anycast.

Continue on Aptranet

What if I cannot wait a day?

You still lower TTL, but accept a tail of users on the old answer. Health-aware records and origin restriction limit the damage.

Should I lower NS TTLs too?

Only if you are changing nameservers. Record TTL and NS TTL are different clocks.

Can Cloud DNS do one second from the start?

Yes for records that need it. You do not have to keep every record there.