The countdown starts the moment you get the answer
Lowering the TTL before you move anything
Cut the TTL before the cutover, or the old address outlives the migration by hours.
The window is set before you touch anything else
Every record in DNS carries a TTL — a number, in seconds, that tells resolvers how long they may cache the answer before asking again. When you move a service to a new address, that number determines how long stale data keeps circulating after you update the zone. A TTL of 86 400 means the old address is legal to serve for another twenty-four hours after you've changed it; resolvers that cached it at the worst possible moment, one second before your edit, will sit on it until the full day expires.
The fix is mechanical but timing-sensitive: lower the TTL to something short — 300 seconds is common — well before the migration window. RFC 1035 defines TTL as a signed 32-bit integer ↗, but the important constraint is practical: the low value must be in cache on every resolver that matters before you make the change. That means you wait for at least one old TTL to pass after publishing the reduced value.
If your current TTL is 86 400, you lower it to 300 and then wait a full 24 hours before touching the address. Rush that wait and some resolvers will still be holding the pre-reduction TTL they cached yesterday, and your short window buys you nothing. This is why the operation is always at least a day's work, never an afternoon's.
The countdown starts the moment you serve the new TTL — not the moment you intend to, and not when you save the zone file. If your authoritative servers are behind a zone transfer to secondaries, secondary propagation adds its own delay: the SOA serial must increment, secondaries must poll or be notified, and the low TTL must reach them before the clock genuinely starts. Check all nameservers in the delegation; a secondary nobody updated still answers with the old value and the old TTL.
Once the migration is complete and verified — traffic arriving cleanly, health checks passing, rollback no longer on the table — raise the TTL back. A 300-second TTL left permanently in place multiplies query load across every caching resolver that handles your zone, and it reduces the protection that a longer TTL gives you against resolver misbehaviour and transient outages.
The whole sequence is: lower, wait, move, verify, raise. Every step that collapses those into one is a step that adds hours of potential disruption to the migration window. The TTL is not a concern you address on the day; it is the preparation you do the day before.
Rush that wait and some resolvers will still be holding the pre-reduction TTL they cached yesterday, and your short window buys you nothing.
The countdown starts the moment you serve the new TTL — not the moment you intend to, and not when you save the zone file.