Lower a relevant DNS TTL before a planned migration, then allow the old cached lifetime to pass before changing the destination. Changing the TTL and address at the same moment cannot shorten the lifetime of answers already stored by resolvers.
IN THIS ARTICLE
01 Plan the records and timing
- List the exact website, mail and service records that will change, including alias targets and IPv6 records.
- Read their current authoritative TTLs and note the longest relevant value.
- Select a temporary TTL supported by the DNS provider and appropriate for the migration. A few minutes may be useful where the service permits it.
- Publish the lower TTL on every authoritative server while retaining the existing destination.
- Wait at least the previous relevant TTL before the cutover, allowing extra time for dependent records or provider-specific behaviour.
For example, if the existing TTL is 3,600 seconds and you change it to 300, plan at least an hour of lead time after the lower value is consistently published. That is a scheduling example, not a promise that every application will switch within five minutes.
02 Make and verify the cutover
Change the intended records, query all authoritative servers and test through representative recursive resolvers. Keep the previous destination available for the overlap window where possible. DNS does not migrate files, synchronise databases or preserve mail already stored on the old server.
After service is stable and rollback is no longer expected, restore an appropriate steady-state TTL. Keep the migration record, old values and verification results with the change approval.
Does a low A-record TTL speed up a nameserver change?
It does not control every related cache. Parent delegation, nameserver addresses, DS records, aliases and negative answers can have separate lifetimes. For a DNS-provider move, prepare both zones and coordinate the actual delegation and DNSSEC plan rather than lowering only the website address TTL.
Can I use zero or a value below the provider's minimum?
Use the supported range. Providers can enforce minimums or automatic TTLs for particular record modes, and aggressive values increase query demand. Choose the lowest useful supported value for the temporary task, verify what is actually published and avoid treating a low TTL as automatic failover or an application availability guarantee.