DNS changes are often described as if every resolver updates at the same moment. In reality, recursive resolvers cache records according to TTL, and clients may also cache results. A safe migration must account for old answers remaining in caches after the authoritative zone has changed.
Inventory records before the change
Export the current zone and identify A, AAAA, CNAME, MX, TXT, CAA and service records. Record the authoritative nameservers and verify which provider controls the zone. Lowering the TTL on one record does not change the TTL of unrelated records or guarantee that every resolver immediately discards its existing cache.
Reduce TTL ahead of the migration
Lower relevant TTL values well before the planned cutover—at least one previous TTL window in advance. If the current TTL is several hours, changing it shortly before migration will not remove answers already cached for that duration. Keep a record of the original TTL so it can be restored after the transition.
Validate the destination first
Test the new origin directly using a hosts override or an explicit Host header and SNI. Confirm TLS certificates, redirects, application health, email routing and firewall access before changing public DNS. A DNS cutover should not be the first time the new server receives a production request.
Use staged traffic when possible
For critical services, use a load balancer or proxy that can shift traffic gradually. DNS-based weighted routing may help, but resolver caching means weights are not exact per-request controls. Monitor both old and new origins during the overlap window.
Verify from multiple resolvers
dig +trace example.com
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Check the authoritative answer separately from recursive resolver responses. Also verify AAAA records; clients using IPv6 may continue reaching an old destination even after the A record is updated.
Rollback plan
Keep the old server operational until traffic has drained and logs show that requests have moved. If the new origin fails, restore the previous record values and continue serving from the old environment. Remember that rollback is also subject to caching delays.
DNS migration is a staged infrastructure change. Pair this runbook with SNI and TLS configuration and origin connectivity troubleshooting.
Architecture and prerequisites
Inventory every DNS record before a migration, including less visible records such as MX, SPF, DKIM, DMARC, CAA, SRV and verification TXT values. Export the zone and identify which provider is authoritative. A web migration that changes only the A record can still break email, certificate issuance or third-party integrations if related records are missed. Record the original TTL and target values so the change can be reviewed and rolled back accurately.
Configuration and implementation
Lower TTL values well before cutover. Resolvers that cached the previous record retain it for the original TTL, even after the authoritative record is changed. Lowering a TTL at the last minute does not invalidate those caches. Keep the old service available for at least the expected cache overlap and account for clients that cache DNS longer than standards require. Restore normal TTL values after the migration is stable.
Security and compatibility
Validate the destination without relying on public DNS. Use a hosts override or an explicit request with the intended Host header and TLS SNI. Test certificate chain, redirects, authentication, uploads, background jobs, database connectivity and outbound integrations. Verify both IPv4 and IPv6 paths. A destination that passes a local homepage check may still fail when real users access API routes or when a worker connects to a third-party service.
Testing and validation
Check authoritative answers and recursive resolver responses separately. Use dig +trace to inspect delegation, then query more than one public resolver. Confirm nameserver glue and DNSSEC status if the domain uses signed zones. A stale DS record or broken delegation can make the domain appear unavailable even when the zone file is correct. Monitor resolver behavior from the regions where customers are located, not only from the administrator’s workstation.
Monitoring and troubleshooting
Plan a traffic overlap period. Keep the old and new origins healthy while caches converge, and use a load balancer or controlled routing method when gradual traffic shifting is needed. DNS weighting is not exact per-request control because recursive resolvers cache answers. Monitor requests on both origins, compare error rates and ensure sessions or writes are not split in a way that causes data inconsistency.
Production operations
Rollback must account for caching too. If the new origin fails, restore the old authoritative values but keep the new environment available until clients stop reaching it. Do not delete the old server immediately after changing DNS. Record who approved the cutover, when TTLs were lowered and which checks passed. Close the migration only after traffic, certificates, email and application monitoring confirm stable behavior.
Operational readiness and lifecycle
Before rollout, define an owner for the configuration, supported versions, dependencies and escalation path. Put configuration under version control and require review for production changes. Verify the implementation with a representative workload and record a baseline so future changes can be compared. Test a failure scenario, a restart and a rollback rather than relying only on a successful happy-path test. Monitoring should expose both the component’s internal health and the user-visible outcome, with alert thresholds that have a documented response. Keep a concise runbook containing diagnostic commands, expected signals, safe retry guidance and recovery steps. Review the design after the first production cycle and whenever an upstream dependency changes. Remove temporary exceptions, rotate credentials where applicable and update compatibility notes. This ongoing ownership is what turns a working configuration into a maintainable production service.
Scenario-based verification
For DNS migrations, verify authoritative nameservers, delegation, DNSSEC, IPv4, IPv6, mail records and certificate validation. Test from multiple recursive resolvers and from the main customer regions. Keep both origins available during cache convergence, and confirm that rollback works even when clients continue using a cached answer.
Performance and capacity validation
Define a measurable service-level baseline before enabling the change. Record normal and peak throughput, error rate, latency distribution, resource consumption and recovery time. A single successful test does not show how the system behaves under concurrency or after a dependency becomes unavailable. Run load tests that resemble real request patterns and include burst traffic, slow clients and large payloads. Compare results with the baseline and investigate regressions rather than accepting them because the deployment completed. Keep test data representative but non-sensitive, and repeat the test after significant runtime or dependency upgrades.
Logging and alert design
Operational logs should make failures diagnosable without exposing credentials or customer data. Include a correlation identifier, component version, action outcome and safe resource reference. Avoid logging bearer tokens, private keys, full database records or unrestricted request bodies. Define retention and access permissions for diagnostic data. Alert on repeated failures, queue growth, resource saturation and missed scheduled work, but ensure every alert has an owner and an action. Review alert noise after rollout and remove rules that do not lead to useful investigation.
Recovery documentation
Document the recovery path as carefully as the setup path. Include prerequisites, permissions, exact verification commands, expected outputs, rollback steps and conditions that require escalation. Test the procedure with someone who did not build the original system; this exposes assumptions that are obvious only to the author. Keep the runbook next to the configuration or source repository and update it when versions or workflows change. Schedule a periodic review so temporary exceptions, obsolete settings and unsupported dependencies do not become permanent parts of production.
Apply these checks to DNS TTL and Propagation: Plan Safe Domain and Server Migrations: retain the test evidence, identify the owner who accepts the production risk and define the conditions that trigger rollback. Re-run the checks after major upgrades or changes in traffic patterns.
