Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Delegation runbook · Beginner · 5 min plus TTL

How to change your nameservers — Swap the Delegation Without Dropping a Record

You are about to hand an entire zone to a different set of nameservers, and anything you failed to copy across simply stops existing the moment it takes.

View WordPress Hosting plansBrowse more How-To Library

The short answer

Treat this as a zone migration rather than a two-field edit: build the destination zone first, diff it record by record against the live one, and only then change the delegation at the registrar. The switch itself is atomic, so parity beforehand is the whole job.

Two clocks then run. Resolvers hold the old NS answer until its TTL expires, and the parent zone at the registry refreshes on its own schedule. Neither is something you can hurry, which is why the diff happens before the switch and not after it.

By the HostingFast team · Reviewed 24 August 2026

Beginner

Skill floor

4

Stages start to end

Free

Support, every tier

Proven

Run on the live stack

You need registrar access, read access to the current zone and the destination nameserver pair. The keyboard time is around five minutes; the wait is bounded by the TTL on the NS records you are replacing.

Nothing here is irreversible — you can put the old pair back — but a rollback also costs a TTL, so the value is in getting the parity right rather than in going quickly.

Dump the zone before you open the registrar

Get the current zone into a file you can read. Query the existing nameservers directly for each type — dig A, AAAA, CNAME, MX, TXT, SRV, CAA against ns1 of the current provider — or export it from their panel if they offer that. Zone transfers are almost always refused, so do not count on dig axfr.

The rows people lose are always the same ones: the MX set with its priorities, the SPF TXT record, the DKIM selector on a long split string, DMARC at _dmarc, a CAA row restricting which authority may issue, and the verification tokens for whatever services you signed up to two years ago.

Two clocks, and only one of them is yours

The first clock is the TTL on the NS records themselves, and it governs how long resolvers keep asking the old nameservers. Read it with dig NS yourdomain.com and plan around the number you actually see rather than the one you assume.

The second is the parent zone. Your registrar sends the new delegation to the registry, and the registry publishes it on its own refresh cycle. You can watch it land with dig NS yourdomain.com @a.gtld-servers.net, which asks the parent directly and skips every cache in between.

DNSSEC will break this if you leave it on

If the domain is signed, the DS record at the registry points at a key held by the old nameservers. Move the delegation without dealing with that and validating resolvers will refuse the new answers outright — not fall back, refuse — and the domain goes dark for anyone using one.

The safe sequence is to remove the DS record at the registrar first, wait for the old DS TTL to expire so resolvers stop expecting a signature, then change the nameservers, and only re-sign once the new provider is authoritative. Check where you stand with dig DS yourdomain.com before you plan anything else.

The rollback, and what you roll back to

Keep the old zone file and the old nameserver pair in a note next to you, and keep the old DNS account open for a fortnight. A rollback is putting the previous pair back at the registrar, which is quick to do and slow to take effect, so the file you exported at step one is the thing that saves you.

On this side, daily backups and self-service restores cover the site itself, and support is staffed at any hour if the parent zone stalls. What we cannot restore is a record you never wrote down, which is why step one is a dump rather than a click.

Hunting down the right domain name before someone else takes it

The stack these steps were measured on

Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.

Backups run daily on every plan, and restoring a file or a database is one action in the panel rather than a support ticket.

  • Zone parity treated as the actual job
  • Both clocks named, with the command for each
  • DNSSEC handled before it bites
  • Engineers on support at any hour

Why HostingFast

Standard on every plan

Parity before the switch

The page is built around diffing two zones, because the delegation change itself is a single atomic edit that cannot be done partially.

Both clocks explained

The NS TTL and the parent zone refresh are separate waits, and each one comes with the query that shows you where it has got to.

DNSSEC named early

A signed domain with a stale DS record fails hard for validating resolvers, so it appears here before step one rather than in a support ticket.

4 steps, no padding

Four discrete actions, each with a check, and the waiting is described as waiting instead of being dressed up.

A rollback you can actually run

The old pair and the old zone file are kept deliberately, so reverting is a decision rather than an archaeology project.

Engineers on call

If the registry refuses the new delegation, support answers at any hour and will say which side is holding it up.

Quick Start

From order to online

  1. 1

    Dump the live zone to a file

    Query the current nameservers for every record type and save the output, priorities and TTLs included. Read the MX rows, the SPF and DKIM TXT records, DMARC at _dmarc and any CAA row twice. This file is the only thing standing between you and a record you cannot remember.

  2. 2

    Build the destination zone and diff it

    Create every row here first, then query the new nameservers directly with dig @ns1.new.example and compare the answers line by line against the file. Do not rely on the two panels looking similar; compare what the servers actually return.

  3. 3

    Clear DNSSEC, then change the delegation

    Check dig DS yourdomain.com. If a DS record exists, remove it at the registrar and wait out its TTL first. Then replace the full nameserver set at the registrar — both entries, not one — and save.

  4. 4

    Watch the parent, then test mail last

    Track the change with dig NS yourdomain.com @a.gtld-servers.net until the parent returns the new pair, then confirm from 1.1.1.1 and 8.8.8.8. Finish by sending a message in and out, because mail is what a missing row breaks first.

Built In

Loaded onto every plan

  • Support staffed by humans, every hour of the day
  • WordPress Toolkit, with updates applied for you
  • Daily backups with self-service restores from the panel
  • cPanel, the control panel most of the industry already runs
  • 99.9% uptime as the target, monitored around the clock
  • Year one of the domain free when you order annually
  • DDoS filtering absorbed at the network edge
  • Webmail in the browser plus IMAP, POP and SMTP
  • Mailboxes that run on your own domain name
  • WebP conversion built in, at no extra cost

Frequently Asked

What people ask us most often

How do I diff two zones when zone transfers are refused?

Loop dig over the record types against each nameserver in turn and compare the output. Something like for t in A AAAA CNAME MX TXT SRV CAA; do dig +noall +answer $t yourdomain.com @ns1.old.example; done, then the same against the new pair, gives you two files you can diff directly. It is crude and it catches everything a panel-to-panel eyeball comparison misses.

Will DNSSEC survive a nameserver change?

Not on its own. The DS record at the registry commits to a key held by the current provider, so once a different set of nameservers answers, validating resolvers see a signature that does not match and return SERVFAIL rather than falling back. Remove the DS record, wait out its TTL, change the delegation, then re-sign at the new provider.

Can I run both sets of nameservers at once to be safe?

It is possible and it is usually a bad idea. Resolvers pick whichever nameserver answers, so with two authoritative sets holding different data you get non-deterministic answers and a bug that appears to depend on the weather. Keep both zones identical if you must overlap, and reduce to one set as soon as the parent has updated.

Does changing nameservers reset the TTLs I had set?

Yes, in effect. TTLs are properties of the records in whichever zone is now authoritative, so the new provider's values apply from the moment it starts answering, and any default it applies overrides what the old zone said. Set your TTLs deliberately in the destination zone before the switch rather than discovering the default afterwards.

Keep reading

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Move the zone to faster nameservers.

NVMe behind a LiteSpeed cache, free SSL, free migration, and a renewal price identical to the one you signed up at.

View WordPress Hosting plans