Cloudflare DNS TTL: plan propagation before you migrate

DNS TTL and propagation

TTL (time to live) tells resolvers how long to cache a DNS record. It is the single variable controlling how fast your DNS change reaches users, and there is no way to force resolvers to drop a cached record early.

The migration sequence

1. At least 24 hours before the change, lower the TTL on the records you will touch (e.g. to 300 seconds).
2. Wait out the OLD TTL: resolvers that cached the record under the old TTL keep it until that TTL expires. This is the part teams skip.
3. Make the change.
4. Verify propagation from multiple vantage points (dig @8.8.8.8, dig @1.1.1.1, and a resolver on another continent).
5. Raise the TTL back up afterward; low TTLs forever mean more DNS query load for no reason.

The failure modes

• Changing the record and the TTL at the same time: users see the old value for the full old TTL, which reads as "the change did not work" and triggers panicked rollbacks of a correct change.
• Proxied records and TTL: the edge handles the proxying, but the underlying DNS behavior still follows TTL rules during the transition.
• Negative caching: a failed lookup (NXDOMAIN during a gap) also gets cached, by the negative TTL. Keep the old records alive until the new ones are verified.

Checklist

• TTL change first, wait, record change, verify, TTL restore.
• Keep old infra answering until propagation is confirmed, not until the change is "done".

Verified against the live Create DNS records and DNS concepts docs: TTL definition, propagation behavior, recommended TTL management around migrations. Refs: https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/ and https://developers.cloudflare.com/dns/concepts/dns-concepts/