Testing the DNS cutover before you flip

Why you test before the flip

The DNS cutover changes the answer every resolver on the internet gives for your domain at once. You get one quiet window to make it right, and then the entire world's resolvers hold that answer for the TTL. Testing on the real domain, through the live DNS, would affect real visitors. So you test through bypass channels that leave the public record untouched:

• a hosts-file entry makes your machine resolve the domain at the new server while public DNS returns the old;
• forwarded queries against an alternate resolver test the public answer before it goes live;
• dig against the authoritative server checks the record the world would receive.

The goal: prove the new server can answer the domain before a single visitor can be pointed at it by mistake.

Test 1: the new host through the hosts file

Edit the local hosts file so your working machine resolves example.com to the new server's IP (on Linux/macOS /etc/hosts, on Windows C:\Windows\System32\drivers\etc\hosts):

203.0.113.50 example.com www.example.com

Then load the site in a browser, check:

• The http to https redirect works.
• The TLS certificate is issued for example.com and is valid, not just "certificate installed but only for a load balancer".
• A page renders, forms post, and a static asset (image or CSS) is served.
• The SSL and handshake path is clean: no mixed-content warnings, no certificate-name mismatch.

Remove the hosts file entry afterwards; leaving it in place can confuse any later test with the public DNS.

Test 2: the public answer with dig

Once the record is set at the new provider but before the public cutover, confirm the authoritative answer:

dig +short NS example.com @ns1.example.com   # nameservers the domain advertises
dig +short A example.com @ns1.example.com    # the address the public will get
dig +short MX example.com @ns1.example.com   # the mail exchange

Compare with what the current TTL-reduced value is: you want the A/AAAA your new host says it will serve to be the new IP, and the MX to be the new mail server. A mismatch here is cheaper to catch with dig than after the flip. For the new host test, point dig directly at it with +short A @203.0.113.50. This tests the server's own answer without the public change.

Test 3: the external mail test

For one mailbox and one domain, the simplest cutover check is the external one: after the MX change, send from an external account to a different domain and watch it arrive at the new server. The autodiscover test, if the mail client uses it, points the fresh client at the new server only when autodiscover.example.com and autoconfig.example.com resolve to it. The email migration page covers these in the mail-specific order.

The cutover checklist

When the three pre-tests pass, flip the record:

1. Lower the TTL to 300 (or use the TTL already lowered) and confirm the old TTL value before the change.
2. Change the A/AAAA and any CNAME to the new host.
3. After propagation (usually minutes with the lowered TTL), re-check dig +trace example.com @8.8.8.8 from a second location to see the global answer.
4. Confirm the new certificate still matches the public domain by loading the site over https in a normal browser and checking for a certificate warning.

Rollback builds in from the start

Rollback of a DNS cutover is the reverse: put the old A back, and the old mailbox back if mail moved. That is easy within the TTL-bounded window, because the old host is untouched and the old records still exist. The failure handling and no-downtime swap article describes the timed flip and stepping back that the pre-test prevents. Test the rollback path once too: a cut you cannot undo is a bet, not a plan.

The pre-test pattern is universal: a trademark of healthy migrations is that the day of the flip is boring, because every realistic check happened on a scratch copy first.