How to plan a low-downtime DNS cutover

A DNS cutover changes where new lookups send traffic — everyone holding a cached answer keeps visiting the old address until their TTL expires. That overlap window, when both environments receive real traffic at once, is what this entire runbook is designed around.

Establish the current state

Record authoritative nameservers, current A, AAAA, and CNAME values, TTLs, certificate coverage, and the commands used to verify them. Confirm the old origin is healthy and can remain available.

Identify all hostnames involved. The root and www may use different records, and APIs, uploads, or static assets may have separate names.

Lower TTL in advance

Change only the records involved in the cutover to a shorter TTL, commonly several minutes, at least one full old-TTL period before the event. Verify that authoritative servers publish the lower value.

Lowering the TTL immediately before cutover does not shorten answers already cached under the former value.

Test the new origin privately

Use a hosts-file override, private load-balancer address, or controlled preview. Test the public hostname over HTTPS so routing, certificate names, cookies, redirects, and canonical URLs match production.

Validate important requests, database writes, uploads, email, scheduled work, logs, and monitoring. Fix issues before DNS changes.

Control application writes

Decide how orders, forms, accounts, comments, and uploads will stay consistent while both origins may receive traffic. Use replication, shared storage, controlled read-only behavior, or a brief maintenance window and final sync.

DNS alone cannot merge divergent data.

Execute the change

Freeze unrelated deployments. Perform the final data action, confirm destination health, and update the intended records once. Record the exact time and values.

Query an authoritative server and selected recursive resolvers:

dig @ns1.dns-provider.example example.com A +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

Monitor both origins

Watch request logs, errors, transaction counts, queues, database writes, and certificate errors on both sides. Test from multiple networks. Verify redirects, forms, login, APIs, and new content.

Do not shut down the old origin when one resolver shows the new value. Retain it through at least the longest relevant cache window and the agreed observation period.

Roll back when required

If a defined rollback trigger occurs, restore the previous DNS values and keep the destination for diagnosis. Some clients may continue using the new cached value until its TTL expires, so rollback may also require fixing the destination enough to serve safely during that period.

Close the change

After stability is proven, raise TTLs, confirm backups and monitoring, update documentation, remove temporary access, and retire the old origin deliberately. Review the event and keep the exact verification commands for future changes.

Sources and further reading

• RFC 1034: DNS concepts and facilities
• RFC 1035: DNS implementation and specification