How to Change Nameservers Without Downtime

Changing nameservers is one of the few DNS operations that can take a whole domain offline: website, email, API, everything. It rarely goes wrong because of the switch itself. It goes wrong because the new zone was incomplete, because a TTL was a week long, or because DNSSEC was still pointing at the old provider.

This guide is the plan we would follow ourselves. Examples use reserved names and documentation addresses.

What actually happens when you change nameservers

Your domain has NS records in two places:

At the parent (the registry for .com, .org, .com.tr…). These are the delegation. You change them at your registrar.
Inside your own zone, served by your DNS provider. These should match the delegation.

When a resolver needs www.example.com and has nothing cached, it asks the parent zone who is responsible, gets the delegation, and then asks one of those nameservers. Changing nameservers means changing the delegation at the parent.

Nothing is "pushed" to the internet. Resolvers around the world keep using what they have cached until it expires, then ask again and get the new answer. That is why people talk about "propagation", and why it is a misleading word: there is no wave spreading outwards, only caches expiring at different times.

Step 1 — Inventory the old zone

Export the complete zone from the old provider. If there is an export button (BIND format), use it. If not, list every record by hand. The records people forget:

MX, and the TXT records for SPF, DKIM selectors (selector._domainkey) and _dmarc
verification TXT records for search consoles, SaaS tools and certificate issuance
CAA records
SRV records (_sip, _autodiscover, _matrix…)
subdomains delegated elsewhere with their own NS records
wildcard records (*.example.com)

A public lookup only shows names you ask for, so it cannot replace the export. It is a useful cross-check though:

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Step 2 — Build the new zone and test it directly

Create every record at the new provider before touching the delegation. Then query the new nameservers directly, bypassing caches, and compare with the old ones:

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Repeat for every record type and every hostname from your inventory. The answers must match exactly, unless you are intentionally changing something. Resist the urge to combine a nameserver move with a server move: change one thing at a time so that a problem has one possible cause.

Step 3 — Lower TTLs ahead of time

Two TTLs matter:

Your records' TTLs at the old provider. Lower them (300 seconds is common) at least one old TTL before the move. If the old TTL was 86400, do this a day or more in advance.
The delegation TTL at the parent. You do not control this. For many TLDs it is 48 hours (172800 seconds). This is the real length of your migration window.

Because of the second point, plan for both sets of nameservers to answer correctly for at least two to three days.

Step 4 — Handle DNSSEC first

If the domain is signed, the parent holds a DS record that points to the old provider's key. If you switch nameservers while that DS is still in place and the new provider signs with a different key (or does not sign), validating resolvers will treat every answer as bogus. The domain goes dark for a large share of users, and lowering TTLs will not save you.

Check first:

$ dig +short example.com DS

If there is a DS record, choose one approach:

Go unsigned during the move. Remove the DS at the registrar, wait for the parent's DS TTL to expire (often 24 hours or more), change nameservers, then enable DNSSEC at the new provider and publish the new DS.
Do a multi-signer migration if both providers support it: each provider publishes the other's public key before the switch. This keeps the domain signed throughout, but needs cooperation from both sides.

Step 5 — Switch the delegation

At the registrar, replace the old nameservers with the new set. Enter them exactly as the new provider lists them. Some registries run technical checks and reject a change if the new servers do not answer authoritatively for the zone; that is another reason to complete Step 2 first.

Keep the old zone running and unchanged. For the next days some resolvers will still ask the old servers. If you must change a record during this window, change it in both places.

Step 6 — Verify from several places

Check the parent's view directly:

$ dig +trace example.com NS

Then ask several public resolvers and compare. Expect mixed answers for a while. That is normal and does not mean anything is broken, as long as both zones serve the same data.

What to look for:

Which NS set does each location return: old or new? A partial set (one old, one new) is not success.
Do A, AAAA and MX answers match between old and new?
Does HTTPS still present a valid certificate, and does mail still arrive?

Be careful with claims such as "85% propagated". No tool can measure every resolver on the internet. A truthful statement is narrower: "9 of 12 monitored locations return the new nameservers, 2 still return the old ones, 1 could not be checked."

Step 7 — Decommission carefully

Wait at least the parent's delegation TTL plus a safety margin (three days is a reasonable minimum, a week is comfortable) before deleting the old zone. Then raise your record TTLs back to normal values (3600 or more) to reduce query load and improve resilience.

Rollback plan

Before you start, write down the old nameserver names and keep the old zone intact. If something is wrong after the switch:

Fix the record at the new provider if the problem is a missing or wrong record. This is almost always the fastest fix.
If the new provider itself is failing, set the delegation back to the old nameservers. Remember that a rollback is subject to the same caching, so it is not instant either.

Common mistakes

Switching first and recreating records afterwards.
Forgetting DKIM selectors, so mail starts failing DMARC days later.
Leaving a DS record in place when moving to a provider that does not sign with the same key.
Deleting the old zone the same day.
Treating one successful lookup from your own laptop as proof that the move is complete.

Check it with OrbitProbe

Use the DNS lookup to see the records and nameservers public resolvers return for your domain right now, and the WHOIS lookup to confirm the nameservers and DNSSEC state recorded at the registry. In the OrbitProbe workspace you can also create a watch for the exact nameserver set you expect; it reports how many monitored locations match, which still show the old value and which could not be checked.