DNS Migration Checklist for Production Teams

TL;DR
A safe DNS migration is a record-parity and evidence problem. Inventory the current zone, lower TTLs before the cutover, rebuild the new zone, verify the new authoritative nameservers directly, change delegation only after DNSSEC and rollback are ready, then compare public resolver answers until the migration is boring.

Last updated: July 4, 2026

Use this checklist when you are moving DNS providers, changing authoritative nameservers, consolidating domains, or migrating a production app to a new edge/network provider. If you are only changing one A record, start with how to check DNS propagation. If you are moving a real production zone, use the manifest below.

The migration manifest

Before touching nameservers, create a single manifest that captures the old state, the intended new state, the validation method, and the rollback value. This is the part most migration guides skip. It turns "I think DNS is fine" into evidence your team can re-run before, during, and after the window.

For multi-domain moves, paste the domain list into Bulk DNS Lookup and export the results before the change. DNSBuddy accepts up to 256 targets per bulk request, which is enough for most app, staging, webhook, status page, and customer-domain batches.

Phase 1: Inventory the current zone

Your first job is to prove what exists today. Do not rely on the DNS provider UI alone. Provider dashboards are useful, but the resolver-visible state is what users and mail servers actually see.

Capture at least these record types:

Run direct lookups for the important records:

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com CAA
dig example.com NS
dig example.com SOA

Then compare the same hostnames with Bulk DNS Lookup. The goal is not to admire a spreadsheet. The goal is to have rollback values that are exact enough to use when everyone is tired.

Phase 2: Lower TTLs before the cutover

TTL is the time interval a resolver may cache a DNS record before asking the source again. That definition comes from RFC 1035, and it matters because TTL changes are not retroactive. If a resolver cached your old A record for 86,400 seconds, lowering the TTL now does not erase that resolver's existing cache.

For planned migrations, lower critical TTLs 24-48 hours before the change window. Cloudflare's migration prep guidance recommends lowering critical record TTLs ahead of cutover, with 300 seconds as a common short migration TTL. That is the right default for most production moves: short enough to reduce stale-cache pain, not so low that you forget to raise it later.

Use this timing:

Negative answers are cached too. RFC 2308 defines negative caching for answers like NXDOMAIN and NODATA, and ties the cache time to SOA behavior. In practice: if you add a brand-new hostname after resolvers recently cached "that name does not exist," some users can keep seeing NXDOMAIN until that negative cache expires. Check the SOA record when a new hostname looks stuck.

Phase 3: Build the new zone and compare parity

Create the full zone at the new provider before changing nameservers. Do not make the registrar switch first and then fill in records. That is how email, ACME validation, and forgotten subdomains go missing.

For each record, compare:

1. Name: apex, subdomain, wildcard, or service label.
2. Type: A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, SOA.
3. Value: target host, IP, TXT string, priority, or policy.
4. TTL: temporary migration TTL or normal TTL.
5. Provider behavior: proxy mode, flattening, automatic CAA, or DNSSEC defaults.

Query the new provider's authoritative nameservers directly before delegation changes:

dig @new-ns1.example-dns.com example.com A
dig @new-ns1.example-dns.com example.com MX
dig @new-ns1.example-dns.com example.com TXT
dig @new-ns1.example-dns.com www.example.com CNAME

If the new authoritative nameserver is wrong, public propagation checks are noise. Fix the new zone first. Only move the registrar delegation after the new provider returns the expected records directly.

Phase 4: Handle DNSSEC before changing nameservers

DNSSEC is where otherwise careful migrations get weird. If the old DNSSEC chain remains at the registrar while the new provider serves unsigned records or different keys, validating resolvers can return SERVFAIL.

Cloudflare's DNSSEC documentation gives the safe rule: if your current provider does not support an active multi-signer DNSSEC migration, remove the old DS record at the registrar and wait for the DS TTL to expire before changing nameservers. Cloudflare notes that changing nameservers before the old DS TTL expires can cause validating resolvers to return SERVFAIL because cached DS records do not match the new provider's keys.

Checklist:

1. Check whether DNSSEC is enabled:

dig example.com DS
dig example.com DNSKEY

2. If DNSSEC is enabled, choose one migration path:

   • Active/multi-signer migration if both providers support it.
   • Temporary DNSSEC disablement if they do not.

3. If disabling DNSSEC, remove the DS record at the registrar and wait for the DS TTL to expire.

4. Change nameservers only after validating resolvers no longer expect the old DS chain.

5. Re-enable DNSSEC at the new provider after the delegation is stable.

Do not treat DNSSEC as a checkbox you can clean up later. It is part of the cutover plan.

Phase 5: Cut over nameservers

When the old state is captured, TTLs are lowered, the new zone is verified, and DNSSEC is handled, change nameservers at the registrar.

Immediately record:

• Time of change.
• Old registrar nameservers.
• New registrar nameservers.
• Person who made the change.
• Change ticket or incident link.
• Rollback cutoff time.

Then run the same checks from the manifest:

dig example.com NS
dig @8.8.8.8 example.com NS
dig @1.1.1.1 example.com NS
dig @9.9.9.9 example.com NS

Use DNS Lookup to compare Google, Cloudflare, Quad9, and OpenDNS side by side. Resolver disagreement is normal during the TTL window. What is not normal is a new authoritative nameserver returning incomplete records.

Phase 6: Verify services, not just records

DNS answers can be correct while the service is still broken. After the resolver checks pass, verify the systems those records support.

For web traffic:

• Apex and www resolve to the intended IPs or CNAMEs.
• HTTP redirects still land on the canonical hostname.
• TLS certificates cover the final hostname.
• CDN/proxy mode matches the plan.

For email:

• MX records resolve with the intended priorities.
• SPF still includes every legitimate sender. Use the SPF setup guide if you need to rebuild it.
• DKIM selector records exist.
• DMARC exists at _dmarc.example.com.
• Sending IPs have PTR records and forward-confirmed reverse DNS when you control that layer.

For domain and registrar state:

• WHOIS/RDAP shows the expected registrar and expiry data.
• Registrar lock settings did not change unexpectedly.
• Nameservers at the registrar match the intended set.

Use Bulk WHOIS for domain-fleet moves, and Bulk FCrDNS when mail-sending IPs are part of the migration.

Phase 7: Keep the old zone alive

Do not delete the old zone immediately after the registrar update. Some resolvers may still have the old delegation cached, and some users may still reach old infrastructure while caches expire.

Keep the old DNS provider and old backing services available for at least the longest relevant TTL window. For nameserver migrations, a 48-72 hour overlap is a sensible default unless your TLD, registrar, or enterprise resolver environment requires longer.

Rollback should be boring:

1. Revert registrar nameservers to the old provider.
2. Confirm the old zone still has the exact old records.
3. Keep the new zone unchanged until the incident is reviewed.
4. Record which check failed so the second attempt fixes the real issue.

The rollback value is not "old DNS." It is the exact record, TTL, and provider state you captured in the manifest.

Phase 8: Restore TTLs and close the loop

After the migration is stable, raise TTLs back to normal values. Leaving every record at 300 seconds forever creates extra query volume and makes your DNS setup look permanently in-change.

Before closing the change:

• Confirm public resolvers agree on NS, A/AAAA, MX, TXT, CAA, and key service records.
• Confirm no SERVFAIL responses from validating resolvers.
• Confirm no NXDOMAIN for new production hostnames.
• Confirm email authentication records are present.
• Confirm FCrDNS for sending IPs where applicable.
• Export the final state and attach it to the change record.
• Update runbooks, provider ownership notes, and monitoring targets.

Then schedule a follow-up audit a week later. DNS migrations are famous for "everything worked until certificate renewal" and "marketing email broke Monday morning." A delayed audit catches the records that do not fail immediately.

Copy-paste DNS migration checklist

Use this as the short version in your change ticket:

Pre-cutover
[ ] Export or inventory all DNS records
[ ] Capture registrar, nameserver, WHOIS/RDAP, and expiry state
[ ] Capture rollback values for all critical records
[ ] Lower TTLs 24-48 hours before cutover
[ ] Rebuild the new zone completely
[ ] Verify new authoritative nameservers directly with dig
[ ] Compare A, AAAA, CNAME, MX, TXT, CAA, SRV, NS, and SOA records
[ ] Confirm SPF, DKIM, DMARC, and verification TXT records
[ ] Check CAA records for certificate issuance
[ ] Check DNSSEC DS state and wait for DS TTL if needed
[ ] Freeze unrelated DNS changes
 
Cutover
[ ] Change registrar nameservers
[ ] Record cutover time and rollback owner
[ ] Query public resolvers for NS and key records
[ ] Verify website, API, redirects, TLS, email, and validation records
[ ] Keep old DNS zone and old services alive
 
Post-cutover
[ ] Monitor resolver agreement through the TTL window
[ ] Confirm no SERVFAIL or unexpected NXDOMAIN
[ ] Confirm WHOIS/RDAP and registrar state
[ ] Confirm PTR/FCrDNS for sending IPs if applicable
[ ] Restore normal TTLs after stability
[ ] Export final DNS state
[ ] Keep old zone available for 48-72 hours before decommissioning

Frequently Asked Questions

Related topics

• How to check DNS propagation
• Understanding DNS TTL
• NS records
• SOA records
• Reverse DNS lookup guide
• RDAP vs WHOIS — registrar and expiry lookups after the gTLD WHOIS obligation sunset
• Bulk DNS Lookup