Two operations people lump together as "a DNS change" behave very differently. Editing a record — an A, MX or TXT inside your zone — is fast and under your control. Changing your nameservers — repointing the whole domain to a different DNS provider — is slower and largely outside it. The reason comes down to which zone holds the record that has to change and who owns its TTL.

Two records, two different owners

A record change edits data your nameserver is authoritative for. You set its TTL, so you decide how long a stale copy can survive — lower it to 300 and the change is global in minutes.

A nameserver change is a delegation change. The record that says "the authoritative nameservers for example.com are these" is the NS record, and the copy that resolvers actually follow does not live in your zone. It lives in the parent zone — the TLD. For a .com domain that is the Verisign-operated .com nameservers; for .co.uk it is Nominet's. You publish your intended nameservers through your registrar, the registrar tells the registry, and the registry publishes the delegation with a TTL it chooses. You cannot lower it.

Why the parent TTL makes nameserver changes lag

TLD delegations are deliberately cached for a long time to reduce load on the registry's servers. Typical values:

Parent NS TTL: commonly 172800 seconds — 48 hours — for .com and many other TLDs.
Glue (address) records: often 86400 seconds — 24 hours.

When you switch providers, every resolver that has cached the old delegation keeps sending queries to your old nameservers until that 24-48 hour parent TTL expires. Until then those resolvers never even see your new provider. This is precisely the origin of the "DNS takes 24-48 hours" folklore — it is true for delegation changes and a myth for ordinary records, as covered in how long DNS propagation takes.

Glue records and why they matter

A glue record is an A/AAAA record for a nameserver, published in the parent zone, that breaks an otherwise circular dependency. If ns1.example.com is a nameserver for example.com, a resolver cannot find its address without already knowing where to ask — so the registry publishes the address as glue alongside the delegation.

Glue is only needed for in-bailiwick nameservers (named under the domain they serve). If your new provider uses names like ns1.provider.net, no glue is required — those resolve via the provider's own TLD.
When you keep the same nameserver hostnames but change their IPs, you must update the glue at the registrar too, and that glue rides the parent's 24-hour TTL. Forgetting it leaves resolvers pointed at dead addresses.
Stale or mismatched glue is a classic cause of a migration that "half works" — some resolvers follow the new delegation, others still hit the old glued IP.

The comparison, side by side

Record change: TTL owned by you; can be as low as seconds; converges in minutes if you prepared. Reversible quickly.
Nameserver change: parent NS/glue TTL owned by the registry; 24-48 hours; cannot be shortened; the old and new nameservers must both answer correctly throughout the overlap.

How to change nameservers with minimal downtime

You cannot beat the parent TTL, but you can make the overlap seamless so no user notices:

Recreate every record at the new provider first. Before touching the delegation, copy your entire zone — every A, AAAA, MX, TXT, CNAME and SRV — into the new nameservers and verify it there. Query the new servers directly (for example dig example.com @ns1.newprovider.net) to confirm they return correct answers before they are live.
Match the data exactly. During the 24-48 hour window some resolvers use the old nameservers and some the new. If both sets return identical records, every user gets a correct answer regardless of which they hit. Downtime only happens when the two disagree.
Keep the old nameservers running. Do not cancel the old DNS service the moment you switch. Leave it serving the same records for several days after the delegation change so late-expiring caches still get correct answers.
Then update the delegation at the registrar, including glue if your nameserver hostnames are in-bailiwick.
Verify convergence from many vantage points. Use Propagation Studio to watch resolvers move to the new nameservers, and confirm the authoritative answers with DNS Studio. Expect it to take up to two days for the last caches to switch.
Only then decommission the old provider. Give it a comfortable margin beyond the 48-hour parent TTL before you tear anything down.

DNSSEC adds a step

If your domain is signed with DNSSEC, a nameserver change is more delicate: the DS record in the parent must match the signing keys at whichever nameserver a resolver follows. A naive switch can leave validating resolvers with a broken chain and hard failures. Either remove DNSSEC before the move and re-enable it after, or coordinate a proper key hand-off between the old and new providers so both sets validate throughout the overlap.

The takeaway

Record changes are fast because you own the TTL; nameserver changes are slow because the registry owns the parent NS and glue TTLs, typically 24-48 hours, and nothing you do can shorten them. You cannot make a delegation change quick — but by duplicating your zone at the new provider first, keeping both live through the overlap, and only then flipping the registrar, you can make it invisible.

← Back to the propagation checker

Nameserver change vs record change: which is slower and why