The DNS migration checklist: every step to move DNS without downtime

Record who controls the registrar, current DNS provider, destination, web origin, mail system, certificate automation, and every SaaS verification record. Start with dig +short NS example.com and confirm the result in the registrar account. Test MFA and the nameserver-edit permission now; do not assume a registrar transfer lock also blocks nameserver edits, because providers implement separate lock types. This is an access check, so there is no DNS wait.

Use the provider API or its zone-file export, not a list assembled from public queries. Save the raw export with a timestamp and keep a second read-only copy. Public DNS cannot enumerate arbitrary DKIM selectors, verification TXT records, delegated subdomains, or names that have never been queried. Use the DNS migration checker as an outside view, not as the source inventory. Export before planning and again immediately before the change freeze so late edits are visible.

Mark proxied records, redirects, health checks, failover or geo rules, weighted answers, and apex ALIAS/ANAME or flattened CNAMEs. For each one, write the destination representation and an application test. An apex hostname target may need a provider-native alias rather than a literal CNAME; the apex CNAME and ALIAS guide explains why. Resolve every unsupported feature before creating the cutover window; waiting on DNS will not repair a semantic mismatch.

Query the current authority for representative record TTLs and the parent for NS and DS. For a .com domain, a direct parent query looks like this:

dig +norecurse +noall +authority @a.gtld-servers.net example.com NS
dig +norecurse +noall +answer @a.gtld-servers.net example.com DS
dig +norecurse +noall +answer @ns1.old-provider.example example.com SOA

On September 27, 2026, the first command returned a 172800-second NS TTL for example.com; your TLD may differ. Record the largest old application TTL, parent NS TTL, old DS TTL, SOA TTL, and SOA minimum. These values determine every later wait.

Choose who can make DNS changes during cutover, where alerts arrive, and what triggers a pause or rollback. The simplest rule is a freeze from the final export until the old delegation TTL has elapsed. If a change cannot wait, require it on both authorities and query both before closing the ticket. Save the original NS set and decide who may restore it. A nameserver rollback is another cached delegation change, not an instant cache purge.

Import the saved zone through an API or BIND file. Let the destination manage its own SOA, DNSKEY, signatures, and apex NS records; preserve NS records that intentionally delegate child zones. Compare the imported RRset count by type with the source export, but do not accept equal counts as proof. Because the destination is not delegated yet, there is no recursive-cache wait; finish before the final comparison and change freeze so mismatches can be corrected.

Check apex A/AAAA or alias behavior, www, API and static hosts, wildcards, CAA policy, _acme-challenge, and every ownership-verification TXT name from the source inventory. Query both sides directly:

dig +norecurse +noall +answer @ns1.old-provider.example example.com A
dig +norecurse +noall +answer @ns1.new-provider.example example.com A
dig +norecurse +noall +answer @ns1.old-provider.example example.com CAA
dig +norecurse +noall +answer @ns1.new-provider.example example.com CAA

Compare owner, type, complete value set, priority where present, and intended TTL. RRset order does not matter. Correct a mismatch and wait only for the destination provider to publish it to all of its own nameservers; direct queries show when that has happened.

Compare all MX values and priorities, the complete SPF TXT policy, every active DKIM selector supplied by each sender, and _dmarc. Also verify the A/AAAA records of any in-zone MX targets. The email-safe DNS move guide covers the inventory in detail.

dig +norecurse +noall +answer @ns1.new-provider.example example.com MX
dig +norecurse +noall +answer @ns1.new-provider.example example.com TXT
dig +norecurse +noall +answer @ns1.new-provider.example selector1._domainkey.example.com TXT
dig +norecurse +noall +answer @ns1.new-provider.example _dmarc.example.com TXT

Do not wait for recursive caches yet; these are direct authority checks. Do wait until every destination nameserver returns the same intended RRsets.

Generate a list of every owner and type from the export, then query each old and new nameserver with dig +norecurse. Compare RRsets rather than dashboard rows, including multi-value TXT, MX, SRV, CAA, TLSA, SSHFP, NAPTR, and subdomain NS sets. Require the aa flag from the intended authority. DNSMigrator’s migration preview states label rows Exact, Translated, Review, Unsupported, or Managed; resolve every review item or unsupported row before switching.

Exercise HTTPS with the production hostname and the candidate address:

curl --resolve www.example.com:443:192.0.2.44 \
  --fail --show-error https://www.example.com/health

Check the certificate, redirect chain, status, expected body, and application dependencies. This tests the endpoint, not DNS or a removed CDN/WAF feature. Run it after each origin or edge-policy change and again immediately before cutover; no cache wait is involved.

Lower A, AAAA, CNAME, MX, and other records you may need to change quickly. A 300-second target is common, but use a value both providers support. Confirm the lower value directly at every old authority, then wait at least the largest previous TTL. If an A record was 3600, wait 3600 seconds after all old authorities serve 300; only then can no compliant recursive cache still hold the earlier one-hour copy. Follow the TTL preparation guide. Lowering these records does not shorten the parent NS TTL.

If the DNS operators cannot coordinate keys, remove the old DS at the registrar while the old signed zone still answers. Confirm the parent no longer publishes it, then wait at least the old DS TTL so cached DS RRsets expire. Keep the old DNSKEY and signatures available during that wait. Validate the resulting insecure delegation with the DNSSEC migration checker before changing NS. RFC 6781 section 4.3.5 describes operator changes; never copy the old provider’s private signing setup as ordinary zone data.

Query every destination authority for every expected RRset, then query a deliberately absent name and compare the response code and SOA behavior with the source. Run the zone diff tool for a second representation. If anything changes, restart the affected verification; if a lowered record had already been cached, wait its current TTL before relying on recursive tests.

Save current latency and success results for HTTPS, inbound and outbound mail, certificate issuance, API hosts, VPN/SIP/service records, and important TXT verifications. Configure alerts against more than the apex website. Send a labeled inbound and outbound message and retain headers. Do this immediately before the switch, after the freeze starts, so an existing failure is investigated rather than carried into cutover.

Open the exact nameserver form, verify the destination NS hostnames, account recovery path, MFA, change approval, and any registry-specific validation. Check whether a domain lock affects transfers, nameserver edits, or both; unlock only what the registrar requires. Do not combine an unrelated registration transfer with this DNS change. Complete the access check before the maintenance window because support escalation can outlast any TTL.

Start the agreed freeze, export the source again, and diff it against the reviewed snapshot. DNSMigrator reads and snapshots the live destination during apply, rebuilds the create/update/delete plan from its current records, and writes that fresh plan. When the operation keys differ from the preview, the timeline records the re-plan. Because apply does not pause for a second review, return to preview if the source or destination changed. This gate has no fixed DNS wait: proceed only when the final evidence matches.

Replace the registrar’s NS set with the destination’s complete assigned set. Query multiple parent authorities directly until they return the new delegation, and record the first time all checked parents agree:

dig +short com NS
dig +norecurse +noall +authority @a.gtld-servers.net example.com NS

Use the parent servers for the real TLD. Start the old-provider retirement clock from confirmed parent publication, not from clicking Save at the registrar.

Do not delete or disable the old zone. A resolver that cached the old delegation can continue querying it for up to the parent NS TTL; a resolver without that cache may use the new authority immediately. Maintain the freeze for that full measured interval. If an emergency record change is unavoidable, apply it to both sides, query every authority, and wait the old record TTL before expecting all recursive answers to converge.

Use direct parent queries for delegation, direct authority queries for zone contents, and recursive queries for cache observations. The propagation checker samples resolver views, while the propagation timing guide explains their clocks. Check immediately, throughout the parent NS TTL, and once more after it ends. A broad sample is evidence of adoption, not proof that every private cache has expired.

Repeat the baseline tests from at least two networks. Send mail in both directions; inspect the receiving headers for SPF, DKIM, and DMARC results; load HTTPS without --resolve; and exercise API and service names. Check certificate renewal challenges and CAA. Run immediately after parent publication, periodically during overlap, and after the full NS TTL because those points cover new and old cache paths.

After the new delegation is stable, enable signing at the destination, query every new authority for DNSKEY and signed answers, then publish the destination’s DS through the registrar. Confirm the DS at the parent and validate the chain. Keep the destination keys published continuously. Wait the parent’s DS TTL before treating the new secure state as universal; the DNSSEC cutover guide has the full checks.

Restore normal TTLs after functional checks pass and the old parent NS TTL has elapsed. Confirm the new values at every destination authority. Raising a TTL is safe immediately for correctness, but it makes the next correction slower, so wait until rollback risk is low. Recursive resolvers adopt the higher value as they refresh each RRset.

Fix or restore the old zone first, then request the original NS set at the registrar and verify it at the parent. Some resolvers may already cache the new delegation for its NS TTL, so the destination must also remain correct during the reverse overlap. DNSMigrator does not silently revert a failed cutover; the user can choose Switch back to the old provider in the cutover flow.

Keep every old authoritative server online and equivalent for at least the full parent NS TTL after all checked parent servers published the new NS set. For the live .com example that minimum was 172800 seconds, or 48 hours; it is not universal. Add the margin required by your change policy, and restart the interval if you reverted or changed delegation again. Do not use a propagation sample as the cancellation clock.

After the wait, query parent NS and DS, every new authority, representative recursive resolvers, web, mail, and certificate automation. Save the final source export, destination export, diff, command output, timestamps, and ownership notes. Remove obsolete API credentials and automation only after confirming nothing still writes the old provider. There is no further DNS wait once the old delegation interval and final checks are complete.