How to change the nameservers for your domain?

To change the nameservers for your domain, first set up the new DNS provider and recreate all of your existing records there. Then log in to your domain registrar (the company you pay to renew the domain), find the nameserver setting for the domain, switch from the default nameservers to custom ones, and enter the nameserver hostnames your new provider gave you. Save the change, and the registry usually publishes it within minutes, although resolvers can take up to 48 hours to stop using the old nameservers.

Changing nameservers moves control of your entire DNS zone from one provider to another, so it's worth doing carefully. In this guide you'll learn what nameservers actually do, how to prepare the new provider, the change process at common registrars, what to do about DNSSEC, how to confirm the change has reached the registry, and why it takes longer than an ordinary record change.

What Changing Nameservers Actually Does

Every domain has a set of authoritative nameservers: the servers that hold its DNS records and answer questions about them. The registry for your top-level domain (for example, Verisign for .com) publishes NS records that point to those servers.

When you change nameservers, you're changing that delegation at the registry. From then on, resolvers are sent to your new provider for every record in your domain: the website, email, verification records, everything.

That's different from editing individual DNS records:

Change	Where you make it	What moves
Edit an A or MX record	Your current DNS provider	One record
Change nameservers	Your registrar	The whole zone

Because the whole zone moves, any record you forget to recreate at the new provider effectively disappears the moment the new nameservers take over.

Before You Start

You'll need:

• Access to your registrar account, ideally with two-factor authentication turned on.
• An account at the new DNS provider with your domain added as a zone.
• The new nameserver hostnames, which the provider shows when you add the domain, for example ada.ns.cloudflare.com and bob.ns.cloudflare.com, or four awsdns names for Route 53.
• A copy of your existing DNS records.

Check the current nameservers:

dig +short example.com NS

ns1.oldprovider.example.net.
ns2.oldprovider.example.net.

Step 1: Export or List Your Current Records

The best option is a zone file export from your current provider. Most dashboards have this under an "Export" or "Advanced" option, and it produces a standard BIND-format file you can import elsewhere.

If export isn't available, list the records yourself. You can't fetch a whole zone from most public nameservers (zone transfers are normally blocked), so query the names you know about directly against the current authoritative server:

NS=ns1.oldprovider.example.net
for name in example.com www.example.com mail.example.com _dmarc.example.com; do
  for type in A AAAA CNAME MX TXT SRV CAA; do
    dig @$NS +noall +answer "$name" "$type"
  done
done

Don't forget less obvious names:

• DKIM selectors, such as google._domainkey, selector1._domainkey, s1._domainkey.
• Service subdomains: autodiscover, shop, status, help, app, api.
• Verification records at underscore names, such as _acme-challenge or provider-specific challenges.
• SRV records, such as _sip._tls or _autodiscover._tcp.

Look through the old provider's dashboard as the final check. It's the only place that shows every name.

Step 2: Recreate the Records at the New Provider

Import the zone file, or add records manually. Many providers, Cloudflare included, also scan for common records when you add a domain, but treat that as a starting point. Automated scans miss anything at an unusual name.

After importing, compare the two providers by querying both directly. The new provider answers for your domain even before delegation changes, as long as you ask its servers specifically:

OLD=ns1.oldprovider.example.net
NEW=ada.ns.cloudflare.com

for name in example.com www.example.com mail.example.com _dmarc.example.com google._domainkey.example.com; do
  for type in A AAAA CNAME MX TXT; do
    old=$(dig @$OLD +short "$name" "$type" | sort)
    new=$(dig @$NEW +short "$name" "$type" | sort)
    if [ "$old" != "$new" ]; then
      echo "DIFF $name $type"
      echo "  old: $old"
      echo "  new: $new"
    fi
  done
done

Fix any differences before going further. Small TTL differences don't matter, but missing or different values do.

Some providers offer features that change answers, such as Cloudflare's proxy, which returns Cloudflare IPs instead of your origin's. Expect differences for proxied records and leave records that shouldn't be proxied, such as mail server hostnames, set to DNS only.

Step 3: Handle DNSSEC

If DNSSEC is enabled on your domain, this step is essential. There's a DS record at the registry that links to your old provider's signing keys. If you switch nameservers while it's still there, validating resolvers will reject your new provider's answers, and your domain will fail with SERVFAIL for a large share of internet users.

Check whether a DS record exists:

dig +short example.com DS

2371 13 2 1F987CC6583E92DF0890718C42B5A5AF9C2D7E3B3D8F1A7F6B9D3E2A6C8F4B1E

If you get output, the simplest safe approach is:

1. Remove the DS record at your registrar (often by turning DNSSEC off for the domain there).
2. Wait for the DS TTL to expire. Check it with dig example.com DS +noall +answer. For .com, it's typically one day.
3. Change the nameservers.
4. Enable DNSSEC at the new provider and add its new DS record at the registrar once the new nameservers are fully in use.

There are more advanced methods that keep DNSSEC active throughout, by having both providers' keys published during the move, but they require both providers to support importing each other's keys. For most sites, a short period without DNSSEC is the sensible trade-off.

Step 4: Change the Nameservers at Your Registrar

The exact wording varies, but the process is similar everywhere:

1. Log in to the registrar.
2. Open the domain's management page.
3. Find Nameservers or DNS settings.
4. Switch from the registrar's default nameservers to custom nameservers.
5. Enter each nameserver hostname exactly as given, one per field, without trailing dots unless the form asks for them.
6. Remove any old nameservers that are no longer in use.
7. Save.

A few registrar-specific notes:

• GoDaddy: In the domain's DNS settings, choose to change nameservers and select the option to use your own.
• Namecheap: On the domain's Domain tab, change the Nameservers dropdown to Custom DNS and add each server.
• Cloudflare Registrar: Domains registered there must use Cloudflare's nameservers, so you can't point them elsewhere.
• Squarespace Domains, Porkbun, Gandi and others: Look for a nameserver section on the domain detail page.

Don't mix nameservers from two different providers unless both are deliberately serving identical data as a primary and secondary pair. Listing two of the new provider's nameservers alongside one old one means some queries get the old data.

Changing Nameservers With an API

Some registrars allow nameserver changes through their API. Route 53 Domains, for example, supports it from the AWS CLI. Note that the Route 53 Domains API is served from us-east-1:

aws route53domains update-domain-nameservers \
  --region us-east-1 \
  --domain-name example.com \
  --nameservers Name=ada.ns.cloudflare.com Name=bob.ns.cloudflare.com

The command returns an operation ID you can check with aws route53domains get-operation-detail.

Step 5: Confirm the Change at the Registry

Don't rely on your registrar's dashboard alone. Ask the TLD's nameservers directly, which shows exactly what the registry is publishing:

dig +short com NS | head -1
dig @a.gtld-servers.net example.com NS +norec

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  ada.ns.cloudflare.com.
example.com.        172800  IN  NS  bob.ns.cloudflare.com.

For other TLDs, replace com with your TLD, for example dig +short uk NS for .uk or dig +short io NS for .io.

You can also look at the registration data. The whois command still works for most TLDs, although registries have been moving to RDAP:

whois example.com | grep -i "name server"

Or use RDAP directly over HTTPS. For .com and .net, Verisign's RDAP service is public:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq -r '.nameservers[].ldhName'

Why It Takes Longer Than a Record Change

An ordinary record change propagates as fast as that record's TTL. A nameserver change depends on the TTL of the delegation at the TLD, which you don't control. For .com and .net, those NS records have a TTL of 172,800 seconds, or two days.

That means:

• Within minutes: The registry publishes the new nameservers. New resolvers, or ones without a cached copy, use the new provider straight away.
• Up to 48 hours: Resolvers that cached the old delegation may continue asking the old nameservers until their cache expires.

There's one more cache to consider. The old provider's own NS records at the apex of your zone also have a TTL, and some resolvers prefer those over the TLD's referral. If your old provider allows it, lower the apex NS TTL a couple of days in advance.

This is why the most important rule of changing nameservers is: keep the old DNS zone active and unchanged until the switch is complete. If a resolver still asks the old provider, it should get correct answers. Don't delete the old zone or cancel the old account for at least a few days.

Step 6: Check From Multiple Resolvers

After a few hours, check what public resolvers think your nameservers are:

for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo "$r: $(dig @$r +short example.com NS | sort | tr '\n' ' ')"
done

Then do a full trace from the root, which bypasses resolver caches completely:

dig example.com A +trace

The last step of the trace should show the answer coming from your new provider's nameserver.

After the Switch

Once the new nameservers are in use everywhere:

1. Re-enable DNSSEC at the new provider and add the DS record at the registrar.
2. Test email by sending to and from an external address.
3. Check certificate renewals: If you used DNS-based validation for certificates, update any API credentials that pointed at the old provider.
4. Update automation: Scripts, Terraform, dynamic DNS clients and ACME plugins that used the old provider's API need new credentials.
5. Remove the zone at the old provider after a few days, once you're confident no queries are reaching it.

---

FAQ: Changing Nameservers

---

Conclusion

Changing nameservers is a small edit at your registrar with a big effect: it hands your whole DNS zone to a new provider. The edit itself takes a minute. The care goes into preparation: recreating every record at the new provider, comparing both providers directly with dig, and dealing with DNSSEC before you switch.

Once you've saved the change, confirm it with the TLD's nameservers, give resolvers up to two days to catch up, and keep the old zone running until they do. Follow that order, and visitors and email won't notice the move at all.