How to Safely Change Authoritative Nameservers Without DNS Outages

Moving authoritative DNS is not the same as moving a website. Your website IP can stay the same while the DNS provider changes. The goal is to make sure both the old and new DNS providers return the same answers during the switch.

This guide explains how to change nameservers without downtime and avoid two common DNS migration failures:

• NXDOMAIN: A hostname or record is missing on the new provider.
• SERVFAIL: DNSSEC is broken because the DS record and DNS keys do not match.

Your domain registrar controls the public nameserver delegation. For example, the .com registry stores which nameservers are authoritative for example.com.

Your DNS provider stores the actual zone records, including:

• A and AAAA records
• CNAME records
• MX records
• TXT records
• SPF, DKIM, and DMARC
• CAA records
• SRV records
• NS records for delegated subdomains
• DNSSEC keys and signatures

To change nameservers without downtime, the new provider must have a full and correct copy of the zone before you update nameservers at the registrar.

Do not delete the old DNS zone or cancel the old provider during the migration window.

Before changing anything, you must collect the current DNS details:

• Confirm access to the domain registrar.
• Confirm access to both old and new DNS providers.
• Export the old DNS zone as a CSV or zone file.
• Take screenshots if export is not available.
• List all public services using the domain.
• Check if DNSSEC is enabled.
• Freeze DNS changes until migration is complete.
• Keep the old DNS provider active for rollback.

Then, create a local working folder and navigate to it:

Set your domain and nameserver values with:

Save the existing public delegation and important DNSSEC values:

A DS record usually means DNSSEC is active for the domain. You can check the full response if you are unsure:

Cloudflare confirms that an old DS record can cause connectivity errors when nameservers change to a provider using different DNSSEC keys.

TTL means Time To Live. It tells recursive DNS resolvers how long they can cache a record.

Lowering a TTL does not update existing caches instantly. If your A record currently has a TTL of 86,400 seconds, a resolver that cached it can keep it for up to 24 hours.

For a safer migration, you must:

• Lower key record TTLs to 300 or 600 seconds.
• Do this at least one full current TTL before the planned migration.
• For business-critical domains, do it 24 to 48 hours before migration.
• Record the original TTL values before changing them.

Important records to review include:

Before you change nameservers without downtime, make sure you know which records have long TTL values and which records are critical for email. Such as APIs, SaaS tools, certificates, and domain verification.

At this point, you must create the domain at the new DNS provider while the old provider is still authoritative.

Import the zone export if the new provider supports it. Then, compare every record manually. Some DNS providers use special records such as:

• ALIAS or ANAME
• Proxy records
• Health checks
• Traffic steering
• Geo-routing
• Provider-managed DNSSEC
• Flattened CNAME records

These records may not move correctly through a basic zone export.

For a self-managed BIND 9 DNS server, you must install BIND and DNS tools:

Create a folder for zone files with the command below:

Next, run the following command to create the zone file:

You can use this sample only as a starting point. Replace all IPs, mail hosts, and values with your real records:

Once you are done, you must add the zone to BIND. Open the file:

Add this configuration to the file:

Validate the configuration and zone file with the commands below:

Finally, reload BIND and check its status:

BIND’s named-checkconf checks configuration syntax, while named-checkzone validates the zone file before publishing it. rndc reload can reload a specific zone after changes.

Before changing nameservers at your registrar, test the new DNS server directly. This confirms that the new provider has the correct records and can answer DNS requests properly. Use these commands:

The +norecurse option is useful because an authoritative DNS server should answer from its own zone, not fetch an answer from another resolver.

If you use a managed DNS provider, test every assigned nameserver:

Do not continue until every new nameserver returns the expected records.

This is the most important part of the migration. You must compare the old and new DNS records before you change the nameservers. Both providers should return the same answers for every important hostname, including website, email, API, and verification records.

Create a record test list with the command below:

Run a comparison between the old and new authoritative servers:

Review the output carefully. Do not compare only website A records. Missing records can break:

• Email delivery
• SPF validation
• DKIM validation
• DMARC reports
• TLS certificate issuance
• SaaS verification
• API hostnames
• VPN hostnames
• SIP or VoIP services
• Kubernetes ingress hostnames

To change nameservers without downtime, every important hostname must return the same answer from the old and new authoritative servers.

A missing hostname should usually return NXDOMAIN, not SERVFAIL. Test a hostname that should not exist:

A valid authoritative NXDOMAIN response normally includes the domain SOA record in the authority section.

If you see SERVFAIL, stop the migration. Common causes include:

• Broken DNSSEC
• Bad zone syntax
• Missing zone on one nameserver
• Firewall rules blocking DNS
• Invalid DNS provider setup
• Broken delegation

Do not assume SERVFAIL will fix itself through propagation.

DNSSEC is the highest-risk part of a nameserver migration.

A DS record exists at the parent zone, such as .com. It tells validating resolvers which DNSKEY records should be trusted for your domain.

If the registrar still publishes the old DS record but the new provider serves unrelated DNS keys, validating resolvers can reject the zone and return SERVFAIL. Cloudflare recommends removing the old DS record, waiting for its parent-zone TTL to expire, then changing nameservers when using the standard DNSSEC migration path.

Check the current DNSSEC state:

If there is no DS record, migration is simpler:

1. Create the full destination zone.
2. Compare old and new authoritative answers.
3. Change nameservers at the registrar.
4. Verify DNS globally.
5. Enable DNSSEC at the new provider if needed.
6. Add the new provider DS record at the registrar.

Verify DNSSEC after enabling it:

Multi-signer DNSSEC lets both providers serve a coordinated DNSSEC key set during migration.

This method can avoid an unsigned period, but it is advanced and strongly provider-specific. The general order is:

1. Create and sign the destination zone.
2. Enable multi-signer support where required.
3. Exchange or publish the required DNSKEY and ZSK records.
4. Add the destination DS record at the registrar.
5. Keep the old DS record active during the overlap.
6. Add the new nameservers.
7. Remove the old nameservers and DS record only after DNSSEC timing is complete.
8. Remove old imported DNS keys after the old DS TTL safety window.

Cloudflare states that old DNSKEY data should remain available for at least 1.5 times the old DS record TTL after the old DS and old nameservers are removed.

Verify both DNS providers return the required DNSKEY records:

Only use multi-signer DNSSEC if both providers document and support the exact setup.

This is the safest standard process for most migrations. It creates a short period where DNSSEC is disabled, but it avoids a longer outage caused by SERVFAIL.

1. Remove the old DS record at the registrar.
2. Keep the old signed zone and old DNS provider online.
3. Wait for the parent DS TTL to fully expire.
4. Confirm the DS record is gone.
5. Change nameservers at the registrar.
6. Verify the new DNS provider globally.
7. Enable DNSSEC at the new provider.
8. Add the new DS record at the registrar.
9. Verify DNSSEC again.

Check the old DS record:

Check multiple public resolvers:

Wait at least one full DS TTL. For extra safety, wait up to 1.5 times the DS TTL before switching nameservers.

Never remove the old DS record and immediately switch to a new provider with unrelated keys. That is how validating users can get SERVFAIL.

After the destination zone is complete and tested, update nameservers at the registrar.

Use the exact nameserver hostnames from the destination provider. For example:

Do not enter IP addresses unless you use nameservers under your own domain and your registrar asks for them. Record the exact migration time:

If your registrar and DNS providers allow it, you may temporarily use both old and new nameservers during the overlap. However, do this only when:

• Both providers allow mixed NS delegation.
• Both zones contain matching data.
• DNSSEC is planned correctly.
• The new provider does not require an exclusive NS set.

Some managed DNS providers require their full assigned nameserver set and do not support mixed delegation.

If the registrar requires immediate replacement, it can still be safe to change nameservers without downtime because cached resolvers may continue using the old nameservers while fresh delegation requests reach the fully prepared new zone.

After changing the nameservers, you must check that public DNS resolvers can find and use the new DNS servers. Use DNS trace to check the nameserver path:

Test multiple public recursive resolvers:

Check new authoritative servers directly:

Test website access with the following commands:

Also, you must test these:

• Outbound and inbound email
• API endpoints
• VPN hostnames
• SSH hostnames
• Certificate renewal
• SaaS validation
• CDN origin access
• Kubernetes ingress domains

Keep the old DNS provider active for a set time after changing nameservers. This gives you time to find issues and switch back if needed. 

Keep the old zone active for at least:

• The longest NS TTL.
• The longest relevant record TTL.
• The DNSSEC DS TTL, if DNSSEC is enabled.
• Your planned rollback period.

A good rollback window is usually 24 to 48 hours for standard DNS migrations. DNSSEC migrations may require a longer window based on DS TTL. Set clear rollback triggers:

• A critical hostname returns NXDOMAIN.
• DNSSEC validation returns SERVFAIL.
• Email stops working.
• Website or API health checks fail.
• Important TXT records are missing.
• The new DNS provider has an outage.
• TLS certificate issuance or renewal fails.

For an unsigned domain, rollback means restoring the old nameserver set at the registrar and keeping the old DNS zone online.

For a DNSSEC-enabled domain, do not blindly restore old nameservers. Confirm that the DS record, DNSKEY records, and signing provider still match. Save the old data:

To change nameservers without downtime, you need a real rollback option, not only a backup file.

Once the new DNS setup is working correctly, raise your TTL values back to normal. This reduces DNS requests and keeps your records more stable. Common examples:

• 300 to 600 seconds during migration
• 3600 seconds for records that may change
• 86400 seconds for stable records

For BIND zone files, increase the SOA serial before reloading:

Find the SOA record and increase the serial number. For example:

Then validate the zone file:

Reload only the zone and verify the SOA record:

Cloudflare recommends restoring standard TTL values only after DNS is stable and DNSSEC has been re-enabled, if used.

A successful authoritative DNS migration depends on preparation, not DNS propagation luck. The safe process is:

1. Inventory all records.
2. Lower TTL values early.
3. Create a complete destination zone.
4. Compare old and new authoritative answers.
5. Plan DNSSEC DS handling before cutover.
6. Change nameservers at the registrar.
7. Verify delegation and services globally.
8. Keep the old provider active during the rollback window.
9. Restore normal TTL values after stability is confirmed.

The best way to change nameservers without downtime is to make both providers return the same DNS data and treat DNSSEC as a separate timed change. For a controlled registrar-side DNS migration, use PerLod Domain Registration to manage domain delegation.

Also, if the migration includes DNSSEC, WAF, and VPS hardening, review this DNSSEC and WAF security best practices guide before enabling security features on a production domain.