How to Change Nameservers Without Downtime (Step-by-Step)

Changing nameservers moves the authority for your whole domain from one DNS provider to another. Done carelessly, it silently drops records, and your website, email, and verification records stop resolving. Done carefully, nobody notices. The key idea is simple: the new provider must answer correctly before you tell the world to ask it. This guide shows how to make that true and how to verify each stage.

If you are also moving the website to a new host, do that as a separate change; see migrate a website without downtime.

What a nameserver change actually does

Your domain's registrar stores a set of nameserver (NS) records for your domain and publishes them to the registry for the top-level domain (for .com, that is the .com registry). Resolvers follow this chain: root servers, then the TLD servers, which say "ask these nameservers about example.com," then your nameservers, which return the actual records.

When you change the NS records at the registrar, the TLD servers begin pointing resolvers at the new nameservers. Resolvers that cached the old delegation keep using the old servers until that cache expires. This has two consequences:

1. Both old and new nameservers get queries for a while. They must both give the same answers during the overlap.
2. The delay is controlled by the delegation TTL at the TLD, not the TTL of your A records. For many TLDs this is long, often on the order of a day or two. You cannot shorten it by lowering your own record TTLs. Check your registrar's and registry's documentation for specifics.

Read DNS explained for website owners if the delegation model is unfamiliar, and how long DNS propagation takes for realistic expectations.

Step 1: Audit your current DNS

Find your current nameservers and records.

dig +short NS example.com
dig +noall +answer example.com ANY   # many servers limit ANY; query types individually
for t in A AAAA CNAME MX TXT NS SOA CAA SRV; do echo "== $t"; dig +noall +answer example.com $t; done

Querying types one by one is more reliable than ANY. The Nameserver Lookup and DNS Checker show the same information from outside your network. If you can't remember subdomains, check the DNS History tool or your old provider's zone export, and the Subdomain Finder for hostnames you may have forgotten.

Pay special attention to records people forget:

• MX for email, plus TXT records for SPF, DKIM (often a selector._domainkey CNAME or TXT), and DMARC (_dmarc).
• Verification TXT records for Google, Microsoft, and other services.
• CNAME records for www, mail, autodiscover, and SaaS tools.
• CAA records that restrict certificate issuance.
• SRV records for Microsoft 365, SIP, or chat services.

Step 2: Recreate the zone at the new provider

Most providers can import a zone file or scan your existing DNS. Treat scans as a starting point only, since they miss records that can't be guessed (like DKIM selectors or _dmarc). If your old provider can export a BIND-format zone file, import that.

Make sure every record from Step 1 exists on the new provider. Do not change nameservers yet.

Step 3: Query the new nameservers directly

Your new provider gives you nameserver hostnames. Ask them directly, bypassing the public delegation:

dig +short A example.com @ns1.newprovider.example
dig +short MX example.com @ns1.newprovider.example
dig +short TXT example.com @ns1.newprovider.example
dig +short CNAME www.example.com @ns1.newprovider.example

Compare the answers against the old nameservers record by record. A small script helps if you have many records:

OLD=ns1.oldprovider.example
NEW=ns1.newprovider.example
for name in example.com www.example.com mail.example.com _dmarc.example.com; do
  for t in A AAAA CNAME MX TXT; do
    a=$(dig +short $t $name @$OLD | sort)
    b=$(dig +short $t $name @$NEW | sort)
    [ "$a" != "$b" ] && echo "DIFF $name $t"
  done
done

Fix every difference that isn't intentional. This is the most valuable step in the whole process.

Step 4: Handle DNSSEC before switching

If DNSSEC is enabled on the domain, a nameserver change can make the domain fail validation and become unreachable for visitors using validating resolvers. The registrar holds a DS record that must match the signing keys at the authoritative DNS provider. The new provider will usually have different keys.

Check status with the DNSSEC Checker. The safe approaches are:

• Disable DNSSEC first. Remove the DS record at the registrar, wait for the DS record's TTL to expire (check it), then change nameservers. After the move is stable, enable DNSSEC at the new provider and publish the new DS record.
• Or use a provider-supported key rollover that allows both providers to sign during the transition, if both support it.

Do not skip this. A stale DS record at the registrar pointing at keys that no longer exist produces SERVFAIL for validating resolvers, which looks like a full outage. The details are in DNSSEC explained.

Step 5: Lower TTLs on records that may change

While this is not a way to speed up delegation, it helps for any record you may need to correct quickly after the move. Lower important record TTLs (such as A and MX) to a few minutes a day ahead of time at the old provider, then they are copied to the new one. See TTL explained.

Step 6: Change nameservers at the registrar

Log in at your registrar, find the nameserver setting for the domain, and replace the old nameservers with the new ones. Notes:

• Use the exact hostnames the provider gave you, in the number they specify. Mixing old and new nameservers in the same set is risky because different resolvers will get different answers if the zones differ.
• Some registrars require changes to be approved by an email or transfer lock. Check the domain isn't in a state that blocks updates (see domain transfer guide).
• If your nameservers are within the domain itself (for example ns1.example.com), glue records are needed at the registrar. Most people using a provider's hosted nameservers do not need them.
• Confirm the registrar shows the change as saved. Use the WHOIS Lookup to see the nameservers the registry now lists.

Step 7: Monitor the transition

Check what the TLD servers now return, bypassing local caches:

# Ask a TLD server what it delegates
dig +norec NS example.com @a.gtld-servers.net

# Trace the full chain from the root
dig +trace example.com A

For .com domains, a.gtld-servers.net is one of the registry servers. For other TLDs, use dig +trace to see the TLD servers involved.

Then check from public resolvers over the following hours and days:

dig +short NS example.com @1.1.1.1
dig +short NS example.com @8.8.8.8
dig +short A example.com @1.1.1.1

The DNS Checker shows results from different locations. Expect a mix of old and new for a while. That's fine, as long as both give the same answers.

Set up an uptime monitor with DNS-change alerts before you start. SiteDownCheck's monitoring includes DNS-change and SSL alerts, so a stray record change or failing certificate is caught early. Add a check on a keyword from your homepage, and test email by sending and receiving messages and using the MX Lookup.

Step 8: Keep the old zone alive, then clean up

• Leave the old provider's zone and account active for at least a week or longer, beyond the longest delegation TTL you observed, so resolvers with stale caches still get correct answers.
• Keep both zones in sync if you need to change a record during the transition: edit it in both places.
• After the old nameservers stop receiving meaningful traffic, you can cancel. Export a final copy of the zone first.
• Raise TTLs back to normal.
• Enable DNSSEC at the new provider if you had it, and publish the new DS record at the registrar. Verify with the DNSSEC Checker.

When the new DNS is Cloudflare

Cloudflare assigns an account-specific pair of nameservers after you add the site. Before switching, verify imported records and decide which records to proxy and which to leave DNS only. Mail records must not be proxied. See Cloudflare setup: DNS and SSL modes.

Quick troubleshooting

Next steps

• Compare nameserver sets with the Nameserver Lookup.
• Verify records worldwide with the DNS Checker.
• Check DNSSEC with the DNSSEC Checker.
• Plan the full move with migrate a website without downtime.
• Get alerts on DNS changes with the Uptime Monitor.

FAQ

How long does a nameserver change take?

The delegation change at the TLD is usually quick to publish, but resolvers may cache the old delegation for a day or two depending on the TLD. Plan for up to 48 hours of mixed answers and keep the old zone live.

Will my website go down when I change nameservers?

Not if the new zone has every record correct before you switch. Visitors reach either provider, and both return the same answers.

Do I need to turn off DNSSEC first?

If DNSSEC is enabled and the new provider will use different keys, yes: remove the DS record at the registrar and let it expire before the change, then re-enable DNSSEC afterwards.

Can I lower the TTL to speed up the change?

Lowering your record TTLs helps with later corrections, but the time resolvers keep the old nameserver delegation is set at the TLD level and cannot be shortened by you.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.