Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Change nameservers last. A zone can move to a new authoritative DNS host without an outage only when three things are true before the delegation changes: the destination zone matches the source for every record that serves a website, an application, or mail; the DNSSEC path is settled; and the old zone stays live until resolvers have stopped using the old nameservers. The procedure below runs in four gates. The first three happen while the domain still points at the current provider. The fourth is the delegation change itself and the observation that follows it.
The order matters because a nameserver change is hard to unwind cleanly. Once the registrar publishes the new set, resolvers keep using whichever delegation they cached until its TTL expires, so a mistake found after the change produces a period where old and new answers coexist.
What you need before you start
- The names of the current authoritative provider and the destination provider, and the registrar where the domain’s nameservers are edited.
- Whether DNSSEC signing is active on the zone today, and whether a DS record exists at the parent.
- Confirmed access to edit nameserver records at the registrar before the cutover day, not on it.
- A list of every service that depends on the zone: website hosts, application endpoints, mail exchangers, verification records, and API or CDN hostnames.
A DNS migration copies configuration. It does not move the web server, the application, or the mail service. Each record still has to point at the service you intend to run, and gate two is where that is checked.
Gate 1: Inventory and import the zone
Get a complete record list from the current provider
Start from an export of the current zone, not a list typed from memory. A zone export includes records nobody remembers creating, such as old verification TXT records and retired subdomains that still receive traffic. If your provider offers no export, query each name and type you know about and treat the result as incomplete. The AWS zone-file import guide describes the same principle from the destination side: create the destination zone first, then reproduce the records the services need.
#1 Best Overall
Clean the file before importing it
Import tools read owner names and record data according to zone-file rules. A name without a trailing dot can be treated as relative, so the zone name is appended. A bare mail owner becomes mail.example.com., and an MX target written as mx1.mailhost.example without a trailing dot can end up as mx1.mailhost.example.example.com., which points mail at a host that does not exist. AWS documents that this affects record data as well as owner names, so check the value column of every CNAME, MX, NS, and SRV record, not only the names.
- Every fully qualified target in CNAME, MX, NS, and SRV data ends with a trailing dot.
- TXT values keep their quoting, and long strings are split the way the destination expects.
- TTL values are plain seconds in the file, not a mix of seconds and unit suffixes.
- Every record type in the file is supported by the destination provider.
Audit what a record export cannot carry
A zone file captures record text. It does not capture provider behavior. Check the current provider for the following features before you assume the import is complete:
- Weighted, latency, geolocation, or failover routing, which may not survive an import because only the record text is carried over.
- Health checks that stop a record from being served when its target fails.
- Alias or apex-flattening records that point at a load balancer or CDN hostname and resolve through provider-internal logic.
- Provider-specific proxy or traffic settings that change how a hostname is served.
Each of these needs either a designed replacement at the destination or a documented decision to retire it.
Rank #2
Choose how the records move
| Approach | Works best when | Check before you rely on it |
|---|---|---|
| Recreate records by hand | A small zone with few records | Completeness; routing and health-check features have no equivalent in a manual copy |
| Import a zone file | A larger zone, or a transfer you may repeat | Trailing dots, relative names, and unsupported record features; run the gate two diff afterward |
| Zone transfer with AXFR or IXFR | Multi-provider synchronization where both providers support it | Transfer support on both sides, access controls, and sync behavior. Cloudflare documents AXFR as a full zone transfer and IXFR as a transfer of changes since the previous one, in its zone transfer documentation |
Gate 2: Diff the old and new zones
The diff stops silent drift. Compare the source and destination record sets for every name and type, including the records that look unimportant, because a forgotten TXT record is often the one that breaks mail.
What to compare
- Owner name, normalized to fully qualified form before comparison.
- Record type.
- TTL.
- Record data, including MX preference values, SRV weights and ports, and the exact content of TXT strings.
Which differences are expected
AWS’s account-migration guidance states that the outputs should be identical apart from NS and SOA values and intentional changes. The destination provider generates its own NS and SOA records, so those are the planned exceptions. Record them in the change log; do not dismiss them. Every other difference is a finding to resolve before gate three.
| Difference | Status | Action |
|---|---|---|
| Apex NS records | Expected | Record the destination set. You will enter it at the registrar in gate three. |
| SOA record | Expected | Destination-generated. Serial and contact fields are not a mismatch. |
| Record present at the source, missing at the destination | Blocking | Recreate it, or document that it is retired. |
| TTL differs | Investigate | Acceptable only when the change is intentional. |
| Data differs only by a trailing dot or an expanded name | Blocking until normalized | Fix the import, then compare fully qualified forms again. |
| Routing, health-check, or alias behavior lost | Blocking | Design the replacement before cutover. |
| MX, SPF, DKIM, or DMARC data differs | Blocking | Confirm each value. Mail continuity depends on them. |
Run the comparison from the command line
Query each authoritative server directly with recursion turned off. That shows what each provider serves, not what a resolver has cached. The output includes the TTL in the second column, so the same commands also compare TTLs. Substitute your own zone and server names:
dig @ns1.old-host.example example.com NS +norec +noall +answer
dig @ns1.new-host.example example.com NS +norec +noall +answer
dig @ns1.old-host.example www.example.com A +norec +noall +answer
dig @ns1.new-host.example www.example.com A +norec +noall +answerRepeat the pair of queries for every name and type in your inventory. For a zone of any size, script the loop and save both outputs to files so you can run a plain diff. If the current provider allows zone transfers to your IP address, a dig @ns1.old-host.example example.com AXFR gives a full copy to compare against the destination. Many providers refuse it, so treat it as a shortcut when it works, not a requirement.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Gate 3: Confirm delegation and DNSSEC before touching the nameservers
Record the destination set and your rollback set
Write down the exact nameserver hostnames the destination assigns, and the current set at the registrar. Store both in the change record. The current set is your rollback. Without it, reverting means waiting for the old provider to be re-delegated through a support request, which can take far longer than the cutover window.
Find out whether DNSSEC is active
Check the zone and the parent separately. A DS record at the parent tells validating resolvers which keys the zone should be signed with.
dig +short DS example.com
dig +dnssec +short DNSKEY example.comA DS record at the parent with no matching signed zone, or a signed zone with no DS at the parent, is a finding to resolve before any delegation change. A DS record that points at keys the zone no longer serves causes validating resolvers to return SERVFAIL for the domain, so the DS sequence is part of the migration, not an afterthought.
Path A: the standard sequence in AWS’s documentation
AWS’s active-domain migration guidance describes removing the parent DS before the migration and rebuilding the trust chain afterward. The guidance states: “You can’t have DNSSEC signing enabled across two providers at the same time.” Read that as a statement about AWS’s documented procedure. It is the reason to follow that sequence in order, not a general limit on DNSSEC. Expect an unsigned window while the DS record is absent, and schedule the change so the window is short and attended.
Path B: the multi-signer route in Cloudflare’s documentation
Cloudflare documents an advanced multi-signer migration, in which the zone is signed by both providers during the move. Cloudflare labels it advanced. It applies only when the previous provider allows apex DNSKEY records and returns them in answers. Test that before planning around it:
Best Value
- Used Book in Good Condition
dig @ns1.old-host.example example.com DNSKEY +norec +noall +answerIf that query returns no DNSKEY records, the multi-signer route is not available for your pair, and Path A or a provider-specific sequence applies. If it returns keys, you still need the destination’s key exchange and DS and nameserver sequencing, which Cloudflare sets out in its DNSSEC migration tutorial.
| Path | Prerequisite | What happens to the parent DS | Choose it when |
|---|---|---|---|
| A: AWS standard sequence | Follow AWS’s documented steps in order | Removed before migrating; trust chain rebuilt afterward | Your source and destination follow AWS’s published path |
| B: Cloudflare multi-signer | Previous provider allows apex DNSKEY records and returns them in answers | Handled by Cloudflare’s key exchange and DS sequencing | Both providers support the required key behavior |
Do not borrow the AWS disable-and-re-enable sequence for a multi-signer migration, or the reverse. The two paths sequence the DS and key changes differently.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Gate 4: Cut over and watch real traffic
- Lower the NS TTL ahead of time. AWS’s active-domain guidance recommends a temporary NS TTL between 60 and 900 seconds (15 minutes) during migration. The lower value reaches resolvers only after they refresh the previous, longer TTL, so set it well before the cutover date. AWS’s guidance describes 172800 seconds (two days) as a typical NS TTL. If your current value is that long, lowering it takes up to two days to take effect.
- Confirm the TTL at the source. Run
dig @ns1.old-host.example example.com NS +norec +noall +answerand check that the TTL in the second column reflects the lowered value. Resolver caches count down from the old value, so a public resolver will not show the change at once. - Stop making zone edits. Any change after gate two invalidates the comparison. If one is unavoidable, rerun the diff for that record before cutover.
- Replace the nameserver set at the registrar. Enter the destination set you recorded in gate three. Note the time and the exact set entered.
- Verify the destination answers directly. Query each destination server with
dig @ns1.new-host.example example.com SOA +norec. The header should carry theaaflag, which marks an authoritative answer. - Test services, not only DNS. Load the website and application endpoints, send a test message to and from the domain, and check the MX, SPF, DKIM, and DMARC answers from several public resolvers over the following hours.
- Roll back if traffic degrades. Restore the previous nameserver set at the registrar, then investigate. Rollback works only while the old zone still answers, which is why it stays live.
- Restore a typical NS TTL once the transition is healthy. AWS’s example for a typical value is 172800 seconds.
Keep the old zone live
AWS’s hosted-zone migration guidance says not to delete the old zone for at least 48 hours after the nameserver update. Resolvers that still hold the old delegation will query the old servers until their cache expires, and deleting the zone earlier breaks them. Schedule the deletion as its own task, dated at least 48 hours after the registrar change.
Recommended Free Tools
Quick Recap
Troubleshooting mixed answers
- Some resolvers still return old answers after several hours. Their cache still holds the old delegation. Keep waiting, and do not edit the new zone to chase it.
- The new zone returns a different answer for one name. Stop the cutover, correct that record in the new zone, and repeat the gate two comparison for it.
- Validating resolvers return SERVFAIL. Compare the parent DS with the DNSKEY records the zone serves. If they do not match, restore the previous nameservers while you correct the DS or key set.
- Mail fails after cutover. Check the MX and TXT answers from the new servers first. A missing SPF, DKIM, or DMARC record is the most common cause to rule out before anything else.
Scope and limits
- AWS’s active-domain procedure is written for migrations to Route 53. Other providers expose different controls, and their equivalents must be taken from their own documentation.
- AWS’s account-migration guidance covers zones moving between AWS accounts. Apply its record-comparison principle to other moves, but not its account-specific commands.
- Cloudflare’s import and export documentation, last updated April 16, 2026, lists a 256 KiB zone-file size limit and a three-requests-per-minute API limit. These are Cloudflare-specific and can change, so check the import and export page before a large import.
- Cloudflare’s DNSSEC migration tutorial, last updated May 5, 2026, labels the multi-signer route advanced and makes its prerequisites conditional on the previous provider.
- Neither provider’s documentation gives a success rate, downtime figure, or defect rate for zone migrations. The TTL values above are provider guidance, not measured outcomes.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
