A nameserver move changes the whole zone
Build and query the full new DNS zone before changing parent delegation, including mail, verification and DNSSEC dependencies.
Changing registrar nameservers moves authority for the whole zone. Inventory and rebuild web, MX, mail authentication, verification, CAA and child-delegation records before cutover; missing records can break services when old answers expire. Locate the current authority and plan DNSSEC separately where it is enabled.
The domain holder must authorise the registrar change. Record who operates each DNS provider and who can restore the previous delegation. Do not rely on an automatic import alone: provider scans can miss records, including records not visible from a small set of public queries.
Build a verified inventory from the old authority
Export the current zone where available and compare it with direct queries to all delegated old nameservers. List names, types, values and TTLs for apex, www, mail hosts, MX, SPF, DKIM selectors, DMARC, CAA, verification TXT, SRV and any other application records. Include wildcard records and NS delegations for child zones. Ask service owners about unpublished or rarely used dependencies; a DNS export does not tell you which record can safely be deleted.
Record DNSSEC state and the parent DS record at the registrar. A signing-key mismatch can cause SERVFAIL after the move even when the new zone’s ordinary records are correct. Plan the provider-supported DNSSEC migration sequence and its TTLs before changing NS.
Build and query the new zone before cutover
Create the corresponding records at the new provider, using its naming convention for @, relative labels and full hostnames. Preserve MX priorities, trailing names, TXT content and delegated child NS records. Verify that an apex alias feature, proxy mode or CNAME flattening changes public answers only as intended. Keep mail hostnames unproxied where the DNS provider requires it. If a provider automatically creates service records, compare public output with the inventory instead of duplicating them.
A useful pre-cutover check asks each new nameserver for example.com MX and _dmarc.example.com TXT; both should match the intended old-zone values before delegation moves.
Query each new assigned nameserver directly before registrar cutover, for example dig @ns1.new-provider.example example.com MX +noall +answer. Substitute a real nameserver. Check representative A, AAAA, MX, TXT, CAA and delegated child answers. If new servers disagree or cannot answer authoritatively, stop and ask the new provider to repair its zone.
Change delegation in a controlled window
Keep both old and new DNS services available. After the candidate zone and DNSSEC sequence are verified, set exactly the intended new nameservers at the registrar. Avoid mixing old and new NS sets unless both providers are deliberately synchronised. Record the change time and parent delegation result. Existing resolvers may continue to use cached old NS and records until their TTLs expire, so both zones should remain consistent throughout the overlap.
Query parent delegation and each new authoritative server, then use more than one recursive resolver to test website, mail and key application records. Send a real inbound and outbound mail test and check the website over HTTPS. DNS answers alone do not prove those services work.
Recover without chasing caches
If the new authority publishes a wrong record, fix that record there and compare the old zone. If delegation is wrong, restore the recorded old NS set only after assessing cached NS/DS state and confirming the old provider still serves the full zone. If validating resolvers return SERVFAIL while direct answers look right, inspect parent DS and DNSSEC rather than editing website records. Do not cancel the old DNS subscription until the observed overlap and verification are complete.
Escalate with domain, old/new NS, parent DS, sample authoritative answers, time and affected service. Do not provide registrar credentials or a private zone export in a public ticket.
Common questions
Will a new DNS provider find every record automatically? No. Review an export and service inventory.
Can I move just the website by changing NS? NS changes the whole zone; edit web records at the current authority for a web-only move.
Why do users see different answers? Cached delegation and record TTLs can make old and new zones visible during the transition.
Can a DNS export reveal every service owner? No. Review rarely used and delegated records with the people who rely on them.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.