How long does a nameserver change actually take?

Two different clocks are running, and people conflate them. The first is the registry updating your domain's delegation in the TLD zone — once your registrar pushes the change, that usually appears at the TLD nameservers within minutes to a couple of hours. The second is the world's recursive resolvers letting go of the *old* nameservers they already cached, and that's bounded by the old NS record's TTL at the parent zone — commonly 172800 seconds, a full 48 hours, for .com and .net. Most resolvers come around in 2-6 hours in practice, but the honest ceiling is up to two days, and there is no button that forces it.

I changed it hours ago and some visitors still hit the old server. Is it broken?

Almost certainly not — that's the two clocks disagreeing. If the TLD already shows your new nameservers (check the parent, not just your own resolver), the delegation is correct and what you're seeing is resolvers that still hold the old NS records until their cached copy expires. It clears itself. It's only a real problem if the *parent* zone still shows the old nameservers hours later, which means the change never actually registered.

Can I speed up a nameserver change by lowering the TTL first?

Not for the nameserver records themselves, and this trips a lot of people. Lowering TTLs works great for ordinary records (A, CNAME, MX) inside a zone you control, done *before* the change. But the TTL on your NS delegation lives in the parent TLD zone and is set by the registry, not you — so you can't retroactively shorten the copy resolvers already cached. When you switch DNS providers, you're stuck waiting out whatever that parent TTL was. Plan the cutover to keep both old and new zones answering identically during the overlap.

Views: 10

Nameserver Change: How to Check It Took Effect

Changed your nameservers and not sure it took? Check TLD delegation and resolver cache to tell 'still propagating' from actually broken. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

You changed your domain’s nameservers at the registrar — moved from one DNS provider to another, or pointed the domain at your host’s nameservers — and now you’re refreshing the site trying to figure out whether it worked. From your office it loads the new server. From your phone on cellular it’s still the old one. A colleague across the country sees a certificate error. Nothing looks finished, and you can’t tell whether you’re watching a normal rollout or staring at a mistake you need to fix right now.

The reason it’s confusing is that a nameserver change isn’t one event that either happened or didn’t. It’s two separate things updating on two separate clocks, and knowing which one you’re waiting on is the whole game.

Two clocks, not one

When you change nameservers, this is what actually has to happen:

The delegation updates in the parent zone. Your domain’s nameservers aren’t stored in your zone — they’re stored one level up, in the TLD registry’s zone (the .com, .net, .kr servers). This is the delegation: the parent pointing down to “these are the authoritative servers for this domain.” When you save new nameservers at your registrar, the registrar tells the registry, and the registry rewrites that pointer. Once it’s pushed, this part is fast — usually minutes to a couple of hours.
Recursive resolvers let go of the old nameservers. Every resolver that looked your domain up recently cached which nameservers to ask, and it will keep asking those until its cached copy expires. That lifetime is the TTL on the NS records in the parent zone, and for .com/.net it’s typically 172800 seconds — 48 hours. A resolver that cached your old delegation an hour before your change will keep using the old nameservers for up to two more days.

The first clock is “did the change register.” The second is “has everyone noticed yet.” When people say a nameserver change “takes up to 48 hours,” they’re describing the second clock — and it’s almost never the thing that’s actually wrong. What matters is checking the first.

Check the parent, not just your own resolver

The single most useful move is to stop asking your resolver what your nameservers are — it may be holding a cached answer that tells you nothing — and instead check two authoritative sources:

The registry’s record of your delegation. RDAP (the structured successor to WHOIS) reports the nameservers currently registered for your domain at the registry level. If RDAP shows your new nameservers, the delegation registered successfully — clock one is done, and everything else is just cache aging out. If it still shows the old ones hours later, the change didn’t take, and that’s a registrar problem to chase, not a waiting game.
What resolvers around the world are actually returning right now. Querying many public resolvers at once shows you the shape of the rollout: all-new means you’re done, a mix means it’s mid-flight, all-old means either you’re early or the delegation never changed. A mix is normal and self-healing; it is not a bug.

Those two answers together tell you exactly where you are. Registry updated + resolvers mixed = working, wait it out. Registry not updated = broken, go back to the registrar.

Why “I fixed it and it’s still wrong”

The most common trap is fixing a genuine mistake — a typo in a nameserver hostname, the wrong provider — and then watching the wrong answer stubbornly persist, and concluding the fix didn’t work. Two forms of caching cause this:

The old NS TTL is still running. You can’t shorten a copy that’s already cached in some resolver in another country. If the parent TTL was 48 hours, a fix made now still has to wait out that window wherever the bad answer was already stored.
Negative caching. If a resolver looked your domain up while it was genuinely broken and got NXDOMAIN (name doesn’t exist), it caches that failure too, per RFC 2308 — for the duration of the zone’s SOA minimum field. So even after you fix the delegation, some resolvers keep returning “doesn’t exist” until the negative cache expires. It looks like your fix was ignored; it’s just remembering the old failure.

The tell is consistency over time: if the parent shows the right nameservers and the proportion of resolvers returning the new answer keeps climbing every time you check, it’s working. If nothing moves for many hours and the parent still shows the old delegation, it’s not caching — something is actually misconfigured.

Diagnose with DechoNet

Propagation Check queries a spread of public resolvers at once so you can see, in one view, how much of the world has picked up the new nameservers versus how much is still on the old ones. Watch the ratio move; that’s the rollout happening.
RDAP / WHOIS shows the nameservers registered for your domain at the registry — the authoritative answer to “did the delegation actually change,” independent of any resolver’s cache.
DNS Lookup confirms that once resolvers are on the new nameservers, those nameservers return the A, MX, and other records you expect — so you catch the case where the delegation is right but the new zone is missing records.

Verification Checklist

Confirm with RDAP that the registry now lists your new nameservers. If not, the change didn’t register — this is a registrar issue, not propagation.
Run a Propagation Check and read the mix: rising share of new answers = healthy rollout in progress.
Verify the new nameservers actually serve your records (A/AAAA, MX, TXT) with a DNS Lookup, so a correct delegation doesn’t point at an empty zone.
If some resolvers still show the old server, note the old parent NS TTL (up to 48h for .com/.net) and wait it out rather than re-changing anything.
Keep the old DNS provider’s zone answering identically until the overlap window fully closes — don’t delete it the moment the change is saved.

When to Escalate

If RDAP still shows the old nameservers many hours after saving the change, the update never reached the registry. That’s a support ticket to your registrar, not more waiting.
If the delegation is correct but records are wrong or missing, the problem is inside the new zone — see Nameserver Mismatch Diagnosis when the registrar and the active DNS host disagree, and DNS Propagation Delay for record-level (not delegation-level) changes.
If you’re on a Korean host and the change is part of connecting a domain, the provider-specific steps in Cafe24 domain not connecting walk the same three-layer check with that panel’s fields.