DNS TTL & Cutover Planner
The lowered TTL must be shorter than the current TTL, and the cutover time valid.
A concrete timeline for the day you repoint the record.
DNS cutover FAQs
Why lower the TTL before a DNS change?
Resolvers cache a record for up to its TTL, and they learned that TTL when they last asked. A change made under a 24 hour TTL can keep serving the old answer for a full day. Lowering the TTL ahead of time, and waiting out the old TTL, means the actual switch propagates in minutes instead.
How long before the cutover should I lower it?
At least one current TTL before the switch, because that is how long resolvers may hold the old TTL value. If the record sits at 24 hours, lower it at least 24 hours ahead. Earlier is harmless.
Why not just run a 60 second TTL forever?
Every expiry is a fresh lookup, so very low TTLs raise resolver load, DNS bills on per-query pricing, and the user-visible cost of any DNS outage. Short TTLs are a tool for change windows; between changes, longer TTLs make the system calmer and cheaper.
Why does some traffic still hit the old target after the TTL expires?
A few resolvers ignore TTLs or clamp them upward, some operating systems and JVMs pin addresses, and long-lived connections opened before the switch stay on the old target until they close. Plan to keep the old endpoint alive and draining for a grace period rather than cutting it dead at expiry.
Is anything I plan here sent anywhere?
No. The timeline is computed in your browser and the page works offline.