Every DNS record change is really three changes: drop the TTL first so resolvers stop clinging to the old answer, flip the record at cutover, and raise the TTL back once things have settled. This planner sequences those steps against wall-clock time, warns about the exact minutes when clients could still get stale answers, and prints a copy-paste runbook you can drop into a change ticket.
Paste this into your change ticket or the pinned Slack message. All times shown in your selected zone.
The TTL on a DNS record is a resolver's licence to cache: "you may hand this answer out for up to N seconds without asking me again." If you change the record while the current TTL is 24 hours, resolvers around the world can serve the old value for up to 24 hours after your change is authoritative — and there is nothing you can do server-side to make them re-fetch faster.
You have to wait at least one current TTL before every resolver has seen your new low TTL. Only then can you count on their next cache entry being short-lived. The Safety margin above handles clock drift and resolvers that round TTLs up or ignore short values (some enterprise resolvers clamp at 60 s or higher).
Push the new value. From this instant, the worst-case time a client sees the old value is the lowered TTL. Watch traffic, error rates, and connection counts to the old and new endpoints.
Once the new endpoint has been serving fine for at least one lowered-TTL window (so any stale cached queries have expired and re-fetched), raise the TTL back to something sensible — typically hours or a day. Long TTLs cut authoritative-server load, cut client-facing latency (cache hits are ~0 ms vs. ~30 ms for a fresh recursive lookup), and reduce the blast radius if your authoritative provider has an outage.
MINIMUM field or your CDN clamps TTLs to a floor. Some hosted DNS providers refuse TTLs below 30 or 60 s.networkaddress.cache.ttl, some proxies) cache DNS even more aggressively than resolvers.