Does Changing Nameservers Cause Downtime? The Parallel-Serve Rule
Changing nameservers does not cause downtime on its own. It causes downtime when the new nameservers answer differently from the old ones, because for a period after the switch some resolvers are still asking the old set and some have moved to the new one. If both sets return the same records, nobody notices. If they disagree, a fraction of your visitors lands somewhere wrong, and you cannot predict which fraction.
This article covers why a nameserver change behaves differently from an ordinary record change, the one rule that makes the switch safe, the delegation timer you have no control over, and the order to do things in. It ends with what to watch during the window, because the failure mode here is partial and silent rather than total and obvious.
Why a nameserver change is not an ordinary record change
When you edit an A record, you are changing a value inside a zone that one set of nameservers already serves. Every resolver on the internet asks that same set, gets the same answer, and caches it for however long the record's TTL says. The change is bounded by a number you chose and can lower in advance.
A nameserver change is a change to the delegation itself, which lives one level up. You are telling the .com registry, or whichever registry runs your TLD, that a different set of servers is now authoritative for your domain. Until every resolver on the internet has noticed that, the internet holds two opinions about who to ask. Resolvers with the old delegation cached keep querying the old nameservers, and those nameservers keep answering, because nothing has told them to stop. Our guide to how long DNS propagation actually takes covers the underlying caching behaviour in detail, and the delegation case is the slowest version of it.
The parallel-serve rule
Call this the parallel-serve rule: during the overlap window, both sets of nameservers must be able to answer every query correctly. Not one of them. Both.
That single requirement is what turns a risky migration into a boring one, and it reframes the whole task. The job is not point the domain at the new provider. The job is "build a complete, correct copy of the zone at the new provider, verify it answers identically, and only then move the delegation." If you do it in that order, the overlap window becomes irrelevant, because it does not matter which set a resolver asks. Both give the same answer.
The reason nameserver changes have a reputation for causing outages is that people do it in the opposite order. They update the nameservers at the registrar first, then start recreating records at the new provider. For the minutes or hours between those two steps, half the internet is asking a set of nameservers that has an empty or partial zone, and an empty zone does not return a soft error. It returns NXDOMAIN, which means the name does not exist. To a browser that looks exactly like your domain has been deleted.
The delegation TTL you do not control
The overlap window is not a fixed number, and one part of it is set by somebody else. Delegation NS records at the TLD level commonly carry a TTL of 172,800 seconds, which is 48 hours, for .com. That value is set by the registry, not by you and not by your DNS provider. It is the origin of the folklore that DNS changes take 48 hours, and it is the one place that folklore is close to accurate.
Two things soften it in practice. The registrar-to-registry update itself is fast, usually minutes to a few hours, so the new delegation becomes visible quickly to anything that has not cached the old one. And most resolvers refresh delegations well before the full TTL expires. The realistic picture is that the bulk of traffic moves within hours and a long thin tail continues hitting the old nameservers for up to two days. Plan for the tail rather than the bulk. Keep the old nameservers serving the correct zone for at least 48 hours after the switch, and preferably a week. Tearing down the old zone the moment the new one looks live is the single most common way to turn a clean migration into an outage that only affects some people.
The order that makes it safe
Build the zone at the new provider first. Export every record from the old provider and recreate all of them, not just the obvious ones. A records and CNAMEs get remembered. MX, TXT, SPF, DKIM, DMARC, and CAA records get forgotten, and forgetting them breaks email and certificate issuance rather than the website, so the failure surfaces days later in a different department. Our DNS record types guide is a useful checklist for what to look for.
Verify the new nameservers directly before switching anything. Query them by name rather than relying on your normal resolver, which is still using the old delegation. Ask each new nameserver for every record you care about and compare the answers to the old set field by field. This step takes ten minutes and catches the missing MX record before it matters rather than after.
Lower record TTLs in the old zone in advance. This does not affect the delegation TTL, which is out of your hands, but it does mean that if you have to reverse the change, the records inside the zone recover in minutes rather than hours.
Then move the delegation, and leave the old zone alone. Change the nameservers at the registrar and do nothing else. Do not delete the old zone, do not cancel the old DNS account, and do not let it lapse. It is your rollback.
Common mistakes in changing nameservers
Switching the delegation before the new zone exists. This is the mistake that produces the outage everyone associates with nameserver changes. An empty zone answers NXDOMAIN, which is indistinguishable from a deleted domain. Build and verify first, switch second.
Deleting the old zone as soon as the site loads. Your resolver having moved on tells you nothing about the resolvers your customers use. Leave the old nameservers answering correctly for at least the full 48-hour delegation TTL.
Copying only the web records. MX, TXT, SPF, DKIM, DMARC, and CAA are the ones that get missed, and they fail quietly. Email starts bouncing or landing in spam, and certificate renewals start failing at the CAA check, both of which surface long after anyone connects them to the DNS move.
Lowering the TTL on the day of the change. A TTL reduction only takes effect once the old, longer TTL has expired everywhere. To have short TTLs on migration day you have to lower them at least one old-TTL period in advance, which usually means the day before at minimum.
Testing from one location and calling it done. A nameserver change produces partial failures by design. Checking from your own machine samples exactly one resolver out of thousands, and yours is the one most likely to have been flushed already.
FAQ
Does changing nameservers cause downtime?
Not by itself. Downtime happens when the old and new nameservers give different answers during the overlap window, so some resolvers send visitors to the right place and others do not. Build a complete, verified copy of the zone at the new provider before moving the delegation and there is nothing for visitors to notice.
How long does a nameserver change take to propagate?
The registrar-to-registry update is usually minutes to a few hours, but resolvers cache the delegation itself. For .com the TLD nameserver records commonly carry a 48-hour TTL set by the registry, so plan for a long tail of queries still reaching the old nameservers for up to two days.
Can I change nameservers without downtime?
Yes, and it is the normal outcome rather than a lucky one. Replicate the zone at the new provider, verify both sets answer identically, then switch the delegation and leave the old zone running for at least 48 hours.
What happens if I delete the old DNS zone too early?
Any resolver still holding the old delegation queries nameservers that no longer have your zone and receives NXDOMAIN, which browsers treat as a nonexistent domain. The site appears completely down for those users while working perfectly for everyone else.
Closing thought
The thing that makes nameserver changes feel dangerous is that the failure is partial. A broken deploy is obvious because it is broken for everyone including you. A botched delegation change is broken for a shifting subset of strangers while your own browser, which moved on hours ago, shows a working site. That asymmetry is why the parallel-serve rule matters more than any amount of care taken on the day: if both sets of nameservers are correct, there is no subset to be wrong.
Because the failure is partial, checking it from one place proves almost nothing. Odown runs checks from seventeen global locations at intervals down to one minute on every plan, including the twelve dollar tier, which is what turns a migration from a thing you hope went well into a thing you can watch. Regional checks are exactly the right shape for this problem, because a delegation change fails by geography and resolver rather than all at once.
