Introducing DNSMigrator: DNS moves you can check before you make them
A DNS migration tool that previews every record, verifies answers at the new nameservers before cutover and keeps a rollback that only touches its own writes.
7 min readDNSMigrator team
On this page
Changing a delegation takes one registrar action. Knowing that the new authority will answer every query correctly is the hard part. Run the DNS migration checker, then follow the quickstart to move that proof ahead of the nameserver change: preview each record set, write only after typed confirmation, and query the destination nameservers directly before any resolver depends on them.
What a DNS migration tool must do beyond copying#
Provider APIs do not describe the same model. One provider may store an apex alias, another may allow an apex CNAME and flatten it, and a third may require static addresses. A proxied Cloudflare record includes HTTP routing behavior that an ordinary A record cannot carry. Weighted and failover answers may become plain round-robin at a destination without equivalent routing.
A row-for-row copy either fails at the destination or, worse, succeeds while changing behavior. DNSMigrator first normalizes the source into a canonical zone, then translates it against the destination provider's capabilities. Each preview row is labeled Exact, Translated, Review, Unsupported, or Managed. The result says whether a value is preserved, deliberately converted, loses a provider feature, cannot be represented, or is managed by the destination.
For example, the translation engine converts the obsolete SPF record type to TXT when needed, clamps TTLs to the destination's accepted range, and warns when proxying or routing will be lost. It can map an apex alias to a destination alias or flattening feature. If the destination has no safe representation and no current static addresses were supplied, it blocks that row rather than inventing one. See translation rules and how to read a preview. If the source is file-based, first export the DNS zone and learn how to read the BIND zone file format.
How the DNS migration tool verifies the new server#
The useful DNS migration test is not a query through your normal resolver. Before cutover, that resolver should still follow the old delegation. Query the new authoritative server by name instead:
dig +norecurse @ns1.new-dns.example example.com AA healthy, illustrative response looks like this:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr aa; QUERY: 1, ANSWER: 1
;; ANSWER SECTION:
example.com. 300 IN A 192.0.2.44The aa flag matters: it says the server answered from authoritative data. Run the same test for MX, TXT, CAA, SRV, HTTPS, wildcard names, and representative negative answers. Testing only the website apex leaves mail and service-discovery failures hidden.
DNSMigrator does this after apply for every desired record set. It uses the nameservers returned by the destination provider and sends authoritative queries to them. Literal records are compared with their expected values. Alias-like records are queried using the type clients will actually request; when useful, verification also asks the old authority for the resolved answer. A mismatch is recorded per name and type, and verification retries before returning the migration to an applied-but-not-verified state. The nameserver delegation has not changed at this point.
You can follow the same method manually in Apply and verify, build the exact checks from the dig command examples for DNS migrations, or inspect a zone with the DNS record diff and zone diff tools.
Apply reads the live destination again#
A preview is a statement about two snapshots. The destination might change after you review it: another operator adds a TXT challenge, an automation job rotates an address, or a previous deployment completes.
At apply time, DNSMigrator ensures the destination zone exists, reads it again, and saves a before snapshot. It rebuilds the create, update, and delete plan from that live state. If the operation keys differ from the preview, the timeline records that the destination changed, and apply writes the fresh plan. Apply does not pause for a second review, so keep destination changes frozen or run a new preview before confirming.
Migration apply writes only the destination; the source connection is used for reading. The optional cutover TTL-lowering step is the separate exception and explicitly updates eligible source TTLs. After a successful destination write, verification starts against the destination authority. This ordering is the practical difference between “the API accepted my records” and “the nameservers return the intended DNS.”
DNS migration rollback is a compare-and-swap#
A full snapshot restore can erase work that happened after a migration. DNSMigrator instead records the subset of creates, updates, and deletes that its apply actually completed.
Rollback reads the destination again and reverses a create only if that record still equals the value DNSMigrator wrote. It reverses an update only if the current value still equals the migration's after-value. It recreates a deleted record only if the key is still absent. If someone changed one of those records after apply, rollback skips it and reports that decision. Records outside the applied plan are never part of the rollback plan.
That gives you a way back without claiming ownership of unrelated destination changes. Rollback is still time-limited: the current one-time packages provide either seven or 30 days, depending on the migration tier. The detailed behavior is in Rollback.
DNS migration cutover includes the parent zone#
A correct destination zone is necessary but not sufficient. The registry's NS and DS records determine which authority and DNSSEC keys validators trust.
For a signed zone, DNSMigrator's guided and automated cutover sequence is conservative: remove the old DS, wait for cached DS data to expire, switch the delegation, observe propagation, enable signing at the destination, and publish the new DS. Apply and verification must finish before cutover can start. Guided mode tells you what to change; automated mode uses a connected registrar when its API supports the operation. Read DNSSEC transitions and nameserver cutover before scheduling the change.
The old provider must keep serving during the delegation cache window. A resolver that cached the former NS set may continue asking those servers even after the registry publishes the new set. The propagation checker shows observations, but a sample of matching resolvers is not permission to delete the old zone early.
DNSControl's model, with a web workflow#
DNSMigrator also manages zones after a move. The web app covers the DNSControl model: structured records, ignore rules, NO_PURGE behavior, SPF/DMARC/CAA/DKIM/Microsoft 365/LOC builders, import transforms, multiple DNS providers, previews and pushes, drift checks, backups, and dnsconfig.js import and export. The DNSControl parity reference maps each concept to its implementation.
If you prefer local files, the open-source dnsmigrator CLI checks, translates, lints, diffs, and exports zones and can inspect propagation and DNSSEC. It does not take provider credentials. Start with the CLI guide.
Pricing follows the work performed, not the preview. The Free plan is $0 per month and includes previews plus a zone editor for up to three zones. A one-zone Migrate package is $9 for up to 50 record sets with a seven-day rollback window. Migrate + cutover is $29 for any zone size, guided switching, DNSSEC handling, and a 30-day rollback window. Automated is $49 and adds registrar nameserver changes, also with a 30-day rollback window. Current subscription details are on Pricing.
A migration-ready checklist#
- Read the source through its provider API or a complete zone file.
- Review every translated, warning, unsupported, and skipped row.
- Account for proxy, redirect, routing, and apex-alias behavior outside standard DNS.
- Review creates, updates, and deletes at the destination.
- Apply, then require authoritative verification before cutover.
- If DNSSEC is active, schedule the DS wait as part of the change.
- Keep the old authority answering for at least the parent delegation cache window.
- Preserve the rollback window and avoid unrelated destination edits until the move is stable.
A nameserver switch should be the final small step in a migration, not the first moment you learn what the new provider does.