How to Set Up Custom Nameservers for Your Domain

Changing your nameservers decides *who* answers DNS queries for your domain — Cloudflare, your web host, or your own DNS server. It's the master switch that hands DNS control to the right place. This guide shows how to set custom nameservers safely, including the glue-record and DNSSEC traps that catch people.

What nameservers do

Your registrar's job is to tell the world's DNS which servers are authoritative for your domain. Those authoritative servers hold your actual records (A, MX, TXT, etc.). Change the nameservers and you change where all your records are read from. For the concept, see what are nameservers and the wider picture in how DNS works.

There are two common reasons to set custom nameservers:

1. Move DNS to a provider like Cloudflare, Route 53, or your host — you point at *their* nameservers.
2. Run your own DNS — you point at nameservers named after your own domain (ns1.example.com), which needs glue records.

Step 1: Get your target nameservers

• Cloudflare gives you two, e.g. dana.ns.cloudflare.com and rick.ns.cloudflare.com.
• A web host typically gives ns1.host.com, ns2.host.com.
• Your own server — you'll use ns1.example.com / ns2.example.com (more on this below).

Before switching to a provider, make sure your zone there already contains all your records, so nothing drops during the change. This is exactly the pre-flight in how to move your domain's DNS to Cloudflare.

Step 2: Change nameservers at the registrar

In your registrar's panel find Nameservers (sometimes under DNS or domain settings), switch from "default/basic" to custom, and enter the target nameservers:

Nameserver 1:  dana.ns.cloudflare.com
Nameserver 2:  rick.ns.cloudflare.com

Save. The change propagates through the TLD's servers, usually within an hour but occasionally up to 48. Registrar-specific walkthroughs: set up DNS on Namecheap for a VPS and set up DNS on GoDaddy for a VPS.

Step 3: If running your OWN nameservers, add glue

Pointing at ns1.example.com for example.com creates a circular dependency that only glue records solve — the registrar publishes your nameservers' IPs in the parent zone. Register them at the registrar first, then set the domain to use them. The full explanation is in what is a glue record and when do you need one. Running your own DNS also means running DNS software (BIND, PowerDNS) on a server with a static IP.

Step 4: Mind DNSSEC before switching

If DNSSEC is enabled, turn it off at the current host and let the DS record clear *before* changing nameservers — otherwise validation fails and the domain goes dark (SERVFAIL). Re-enable it at the new host afterwards. Details: how to enable DNSSEC on your domain.

Step 5: Verify

dig example.com NS +short

This should list your new nameservers. Then confirm your records still resolve through them:

dig example.com A +short
dig example.com MX +short

If the NS query still shows the old nameservers, the registrar change hasn't propagated yet. If records vanish, the new zone is missing them. Troubleshooting: diagnosing DNS problems with dig and nslookup.

Vanity nameservers for resellers

A common reason to run *branded* nameservers — ns1.yourbrand.com, ns2.yourbrand.com — is reselling hosting so clients see your brand, not your upstream provider's. You don't necessarily run the DNS servers yourself: many DNS hosts and control panels (cPanel/WHM, Cloudflare for SaaS) let you register vanity nameservers that are really CNAME-style aliases to their infrastructure. Either way you register glue records at your registrar mapping ns1.yourbrand.com to the correct IP — the mechanics are in what is a glue record and when do you need one.

Redundancy: always use at least two

Registrars require two nameservers for a reason — if one is unreachable, resolvers fall back to the other and your domain stays up. Best practice:

• Two nameservers on separate infrastructure (different machines, ideally different networks or regions).
• Consider a secondary DNS provider that mirrors your zone, so even a full outage at your primary host doesn't take DNS down. Managed hosts like Cloudflare give you two geographically distributed nameservers out of the box, which is why they're the easy default.

Pointing both nameservers at a single server defeats the purpose — one crash and the domain goes dark.

Verify the delegation actually took

After changing nameservers, confirm the change registered at the parent (registry) level, not just in your own zone:

dig example.com NS +short
dig example.com NS @a.gtld-servers.net +norecurse

The first asks your resolver; the second asks a .com root server directly what it's delegating to. Both should list your new nameservers. If your own zone shows the new NS but the registry query still shows the old ones, the registrar change hasn't propagated — give it up to 48 hours. If they *never* update, the nameserver change didn't save at the registrar, or (for vanity nameservers) glue is missing. Reading this output is covered in diagnosing DNS problems with dig and nslookup, and if you're heading to Cloudflare specifically, how to move your domain's DNS to Cloudflare has the full flow.

FAQ

What's the difference between changing nameservers and changing records?

Nameservers decide *which server* answers for your domain; records are the individual entries (A, MX, TXT) that server holds. Change nameservers to move your whole DNS; change records to tweak specific entries.

How long do nameserver changes take?

Typically under an hour, but up to 48 hours to fully propagate through the TLD. The delegation lives at the registry level, so it's often slower than editing a record.

Do I need glue records for custom nameservers?

Only if the nameservers are subdomains of the domain they serve (e.g. ns1.example.com for example.com). Third-party nameservers like Cloudflare's need no glue from you.

Will changing nameservers break my email?

It can, if the new DNS host doesn't have your MX and email records. Copy every record to the new zone before switching, and verify MX with dig afterwards.

What happens to my website and email during a nameserver change?

If you've prepared correctly, nothing — there's no downtime. Both the old and new nameservers keep answering during the transition, so as long as the new DNS host already contains every record (A, MX, TXT and so on), visitors and mail are served continuously by whichever nameserver a resolver happens to ask. Problems only arise if the new zone is missing records: a forgotten MX breaks email, a missing A record breaks the site. That's why the golden rule is to copy the complete zone to the new host *before* switching nameservers, then verify with dig afterwards. Keep the old zone intact for a week as a rollback path. Done in that order, a nameserver change is invisible to your users.

Whether you point at Cloudflare, a host, or your own DNS server, you need a reliable place to run things. Get a fast NVMe VPS with full root access from Nxeon, or manage registration and DNS together with Nxeon domains.