Four ways a DNS migration breaks, and how to see each one coming

A zone can look complete in a provider dashboard and still fail the minute the parent sends a resolver somewhere else. The useful preflight question is not “did every row copy?” It is “will the new authority produce the same client-visible behavior, and will every resolver be able to trust it?”

Why DNS migrations break when records are missing#

The obvious missing A record is usually caught. The dangerous omissions are names that no one checks during a website-only smoke test: an MX target, a DKIM selector, _dmarc, _acme-challenge, a SIP SRV record, a CAA policy, or a wildcard.

Treat an RRset as the comparison unit. Multiple values at the same owner name and type belong together; order generally does not. This source zone has two mail exchangers and two verification TXT values:

example.com.              300  IN  MX   10 mx1.example.net.
example.com.              300  IN  MX   20 mx2.example.net.
_acme-challenge.example.com. 60 IN TXT  "token-a"
_acme-challenge.example.com. 60 IN TXT  "token-b"
_sip._tcp.example.com.    300  IN  SRV  10 5 5060 sip.example.net.

If an importer treats each dashboard row independently, it can overwrite one value with another. If a zone-file parser mishandles relative names, a record can land under the wrong owner. If a provider manages SOA and apex NS records itself, copying those rows is wrong even though omitting an application TXT record is wrong too.

Compare the old and new authorities directly:

dig +norecurse +noall +answer @ns-old.example _acme-challenge.example.com TXT
dig +norecurse +noall +answer @ns-new.example _acme-challenge.example.com TXT

Illustrative output should contain the same set on both sides:

_acme-challenge.example.com. 60 IN TXT "token-a"
_acme-challenge.example.com. 60 IN TXT "token-b"

DNSMigrator normalizes records into RRsets, previews every source-to-target result, and verifies the desired sets against the destination nameservers after apply. A skipped row is reserved for data the destination manages, such as SOA, DNSKEY, or apex NS in the translation path; an unsupported row needs your decision. The preview status guide explains the distinction.

Provider features do not transfer as DNS records#

Some dashboard objects look like DNS because they are attached to hostnames. They are not equivalent to portable resource records.

A proxied Cloudflare A record stores an origin address plus a proxy flag. Public DNS returns Cloudflare addresses, and HTTP traffic traverses Cloudflare’s network. Copying only the origin A value to an ordinary DNS provider sends clients directly to the origin. Redirect products, worker routes, health checks, geolocation policies, and failover policies have similar gaps: a syntactically valid destination record can remove the behavior that made it safe.

Apex aliases are another semantic boundary. RFC 1034 says a CNAME owner should have no other data. A zone apex necessarily has SOA and NS data, so providers implement nonstandard ALIAS/ANAME records, resource aliases, or CNAME flattening instead. A destination without one of those mechanisms cannot preserve a hostname target at the apex.

DNSMigrator’s migration translator checks the destination capability catalog, but it does not preserve source routing metadata. It flattens routed values into simple answers with a warning, keeps the primary answer for failover groups, and translates aliases into supported destination forms. Rebuild routing at the destination even when that provider has its own routing product. The translator marks loss of proxying as a warning and treats unsupported redirects and provider feature types as blockers; it does not pretend that an A record recreates a WAF or redirect rule.

Review the translation rules, then write a separate application-layer plan for every feature-loss warning. Test HTTP independently from DNS, for example:

curl --resolve www.example.com:443:192.0.2.44 https://www.example.com/health

--resolve exercises the candidate origin while preserving the hostname for TLS and HTTP. It does not test the new DNS provider; authoritative dig queries do that.

DNSSEC migration mistakes cause SERVFAIL#

DNSSEC joins data from two administrative zones. The parent publishes a DS record that identifies a key in the child zone’s DNSKEY set. The child signs RRsets with keys that validators can connect to that DS. During a provider move, the new provider normally creates different keys.

Check each side explicitly:

dig +dnssec +noall +answer example.com DS
dig +dnssec +noall +answer @ns-new.example example.com DNSKEY

A real-shaped response has different record purposes:

example.com. 86400 IN DS     2371 13 2 C988EC42...C83D245A
example.com. 3600  IN DNSKEY 257 3 13 mdsswUyr...L53eKGQ==

The DS is not the DNSKEY copied into another type. Its digest must match the intended child key. If the delegation moves while a cached DS points only to a key the new authority does not publish, validators classify the answer as bogus. A validating recursive server commonly returns SERVFAIL; RFC 4033 defines the secure, insecure, bogus, and indeterminate states.

For a normal move where the providers do not coordinate keys, use an intentionally insecure transition: remove the old DS while the old signed zone still serves, wait at least the old DS TTL after the parent publishes the removal, switch NS, verify propagation, enable signing at the destination, then publish the new DS. Do not remove the old DNSKEY first. RFC 6781 section 4.3.5 covers operator changes, and our DNSSEC transition guide turns the sequence into checks.

The DNSSEC migration checker helps inspect both sides, but the registrar’s parent-zone state remains decisive.

Shutting down old DNS too early breaks some users#

Changing nameservers at a registrar updates the delegation in the parent zone. It does not invalidate NS RRsets already held by recursive resolvers.

On September 27, 2026, a direct nonrecursive query to a .com server returned a 172800-second delegation TTL for example.com:

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

;; AUTHORITY SECTION:
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.

That is 48 hours. A resolver that fetched the old delegation just before your change can legitimately use it for nearly the full interval. Other TLDs and delegations can use different TTLs, so query the actual parent rather than copying this number.

Lowering the A or MX TTL does not lower the parent delegation TTL. It reduces how long answers from whichever authority was queried remain cached. During the overlap, both old and new nameservers therefore need to answer correctly. If records must change, write both sides or freeze changes until the old delegation can no longer be cached.

DNSMigrator’s cutover flow records the original and new nameservers and samples propagation after the switch. Its revert action can put the original NS set back for an automated cutover. Neither action reaches into recursive caches, so the old authority still has to remain available. Use the propagation checker, read why the old provider must keep answering, and follow nameserver cutover.

DNS migration checks before you switch#

• Compare complete RRsets, not dashboard row counts.
• Query old and new authoritative nameservers for web, mail, verification, service, wildcard, and negative cases.
• Review every proxy, alias, redirect, routing, and health-check semantic separately.
• Confirm that unsupported records have an explicit replacement or an accepted removal.
• Query DS from the parent and DNSKEY from the child; never infer DNSSEC state from a green dashboard badge.
• Record the parent NS TTL before cutover.
• Keep both authorities equivalent for that full cache interval plus an operational margin.
• Apply from a fresh destination read, verify before delegation, and retain a scoped rollback.

Use the full interactive DNS migration checklist to save progress and the public DNS migration checker for an outside preflight. The migration succeeds when old caches, new caches, validating resolvers, and direct authoritative queries all have a correct path. A copied record count proves none of those by itself.