How do I plan DNS changes when moving a server?
Update DNS only after the destination is ready and the application’s data transition is controlled. DNS caches can continue using an earlier answer until its remaining lifetime expires. A lower TTL helps only after previously cached records have aged out.
Before you start
- Access to the authoritative DNS zone, current record values and a validated destination.
Instructions
1. Identify the records actually in use
Confirm the delegated nameservers and inspect relevant A, AAAA and CNAME records. Include service names, mail routing or external allowlists affected by the move. Avoid changing nameserver delegation or unrelated records merely because one application server is moving.
2. Prepare the change window
If appropriate, lower the relevant TTL sufficiently ahead of cutover and wait for the old TTL period to pass. Record the old values and the intended new values. Plan how the old endpoint handles remaining clients without accepting conflicting writes after the application changes over.
3. Verify authoritative and client views
After the approved update, query an authoritative nameserver and representative recursive resolvers. Test both IPv4 and IPv6 where configured, and confirm the application served by each endpoint. Retain the old environment only for the agreed transition period and monitor remaining traffic before decommissioning it.
Check the result
- Authoritative answers contain the intended records, and cached clients transition as expected.
- Requests reaching either endpoint during the window cannot create unintended divergent data.
Troubleshooting
- Some clients still reach the old server
- Check their resolver’s cached answer, the previous TTL, local overrides and persistent connections. Repeatedly changing the record can make the transition harder to interpret.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.