What are nameservers? How they work, how to change them and how to check them

Short answer: nameservers are the servers that hold a domain’s DNS records and answer questions about them with authority. Your registrar files their names with the registry of your domain’s extension (.com, .net, .io and so on), and that entry tells every resolver on the internet where to ask. Changing the nameservers moves the whole DNS zone to another provider. Changing a record, such as an A or MX record, changes one answer inside the zone you already have.

$ dig NS example.com +short
elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.

That output says: the authoritative answers for example.com come from two Cloudflare servers. Every A, MX or TXT record for the domain lives there, and nowhere else counts.

How a lookup reaches your nameservers

When someone opens your site and nothing is cached yet, the lookup takes four steps:

1. 1The device asks a resolver

   The “DNS server” in a computer’s network settings (the router, the ISP, or a public one such as 1.1.1.1) is a resolver. It does the legwork and caches the results.

2. 2The resolver asks a root server

   The root servers do not know your domain. They refer the resolver to the servers of the registry for .com.

3. 3The registry hands out the nameservers

   The .com servers do not hold your records either. They answer with a referral: the NS records your registrar filed, plus addresses for them where needed.

4. 4Your nameserver answers

   The resolver asks one of your nameservers, which replies with the record and marks the answer as authoritative. The resolver caches it for as long as the record’s TTL allows.

So two kinds of machine are both called “DNS server”. Resolvers look answers up for clients; nameservers are the source of the answers. When a PC says DNS server not responding, its resolver is the problem, not your domain’s nameservers.

Nameservers vs DNS records

One rule clears up most confusion: records only count at the provider your nameservers point to. If the nameservers are Cloudflare’s, an A record you edit in your registrar’s own DNS editor is never served, however long you wait.

Reverse DNS sits outside your zone entirely, because the IP address belongs to your host, not to your domain. On a VMHeaven VPS you set it in the panel, and changes propagate within about 30 minutes. Mail providers only trust a PTR whose hostname resolves back to the same IP.

How to check a domain’s nameservers

# what your resolver currently believes
dig NS example.com +short

# what the .com / .net registry hands out, asked directly
dig +norec +noall +authority NS example.com @a.gtld-servers.net

# other extensions: find the registry's servers first, then ask one of them
dig NS io. +short

# the registrar's view (Debian, Ubuntu: sudo apt install whois)
whois example.com | grep -i 'name server'

Resolve-DnsName example.com -Type NS
nslookup -type=NS example.com

The first command can return a cached answer. The second asks the registry itself, which is the copy that counts for delegation. Normally both list the same names. If they differ, a change is still in progress, or the zone’s own NS records were not updated to match.

Then ask one of the nameservers directly, without recursion:

dig @hera.ns.cloudflare.com example.com A +norec
# look for "status: NOERROR" and "flags: qr aa" in the header

The aa flag means the server answered with authority. REFUSED or SERVFAIL from a server listed at the registry means it does not carry your zone, a so-called lame delegation. Some networks only let DNS through to their own resolver, so if every @server query times out, run it from a server instead. If dig is missing, dig: command not found has the package.

How to change nameservers at your registrar

1. 1Recreate every record at the new provider first

   A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, site verifications), SRV and CAA. Mail is what breaks most often. Compare before you switch, for example dig @new-ns.example.net example.com MX +short against the current answer.

2. 2Turn off DNSSEC if it is on

   Remove the DS record at the registrar, then wait a day before the switch: resolvers may cache the old DS record that long (the .com registry gives it a 24-hour TTL). Otherwise validating resolvers reject answers from the new provider and the domain stops resolving for many users.

3. 3Replace the nameservers

   In the registrar’s panel, open the domain’s Nameservers or DNS settings, choose custom nameservers, remove all old entries and enter the new names exactly as the provider gave them. Most registries require at least two.

4. 4Check the registry

   Run the @a.gtld-servers.net query above (or the one for your extension) until it lists the new names. Depending on the registrar, that takes minutes to hours.

5. 5Leave the old zone alone for two days

   Resolvers that cached the old delegation keep asking the old provider until it expires, so do not delete or change the old zone yet.

6. 6Turn DNSSEC back on

   Enable signing at the new provider and add the DS record it gives you at the registrar.

Using Cloudflare nameservers

When you add a domain to Cloudflare, it scans for existing records and imports what it finds. The scan can miss records, so check the list against your notes, especially MX and TXT. Cloudflare then assigns two nameservers named <name>.ns.cloudflare.com, which replace all others at your registrar.

Until it sees the change, the zone shows as Pending Nameserver Update. Cloudflare checks first after about a minute and then at growing intervals, and Re-check now on the domain’s overview page queues an early check. Cloudflare says to allow up to 24 hours for the registrar to publish the change. A domain on the Free plan that is never activated is deleted after 28 days.

How long does a nameserver change take?

Two clocks run one after the other:

• Registrar to registry. Usually minutes, sometimes hours. The query against the registry’s servers shows when it is done.
• Caches. Resolvers that looked up your domain before the change keep the old delegation until its TTL runs out. For .com and .net the registry publishes NS records with a TTL of 172,800 seconds, which is 48 hours. The registry sets that value, so you cannot shorten it.

That is why the old and the new zone should hold identical records during the switch: visitors then get the same answer from whichever provider their resolver asks. If you also move the site to a new IP, lower the A record’s TTL at the old provider to 300 seconds a day ahead. To see what different resolvers return, ask them one by one:

dig @1.1.1.1 NS example.com +short
dig @9.9.9.9 NS example.com +short
dig @8.8.8.8 NS example.com +short

The DNS propagation checker asks twelve public resolvers in one go — set the record type to NS — and shows which still hold the old delegation.

Running your own nameservers on a VPS

You can run the authoritative DNS for your domain yourself, with BIND, PowerDNS or Knot. For most sites a managed provider is less work, but if you do it, four things are not optional:

• At least two servers, on separate machines. The DNS standards ask for them to be in different places, so one outage cannot take both down: one VPS in Amsterdam and one in Frankfurt is a simple way to get that.
• Glue for in-domain names. If the nameservers are called ns1.example.com and ns2.example.com, resolvers cannot look them up without already knowing your zone. Register them at the registrar as child nameservers (some panels call them host records or glue records) with their IP addresses, so the registry can hand those out with the referral.
• Authoritative only. Answer for your own zones and nothing else, with port 53 open for UDP and TCP. A server that resolves any name for anyone gets abused for amplification attacks.
• Matching records. The NS records inside your zone should list the same names as the registry.

If such a server stops answering, the section on your own DNS server not responding covers listening addresses, the systemd-resolved port conflict and the firewall.

You may not need to change nameservers at all

To put a website on a VPS, you usually keep the nameservers you have and change the A and AAAA records to the server’s addresses, as described in pointing a domain at your VPS. The same goes for a Plesk hosting account at VMHeaven: the panel lists the records to add at your registrar, and the nameservers stay where they are.

Common nameserver mistakes

• Editing records in the wrong place. The registrar’s DNS editor is ignored once the nameservers point elsewhere. dig NS tells you which panel is live.
• A DS record left behind. Validating resolvers return SERVFAIL. If dig +cd example.com, which skips validation, works while a normal query fails, DNSSEC is the cause.
• Mail records forgotten. Without MX and the SPF, DKIM and DMARC TXT records at the new provider, mail bounces or lands in spam.
• Only one nameserver, or two on the same machine. One outage takes the whole domain offline.
• Expecting reverse DNS to follow. PTR records belong to whoever owns the IP address; set them in the hosting panel, not in your zone.

Frequently asked