How many nameservers should a domain have?

At least two, and ideally on separate networks, so a single server or provider outage doesn't take your domain offline. Many registrars require a minimum of two, and larger operations run four or more across redundant infrastructure.

How long do nameserver changes take to propagate?

Delegation changes at the registry can take up to 24-48 hours because parent-zone TTLs are long and resolvers cache the old NS records. The individual records inside your zone update much faster, governed by their own TTLs.

What's the difference between a nameserver and a DNS record?

A nameserver is the machine that answers queries for your domain. A DNS record (A, MX, TXT, CNAME) is an individual entry it serves. You set nameservers at your registrar and manage records at your DNS host.

What Are Nameservers and How Do They Work?

VigilDog Team · October 24, 2026 · 7 min read

Every domain points at a set of nameservers, and almost every DNS headache traces back to them, yet most people set them once and never think about them again. So let's answer it properly: what are nameservers, what do they actually do, and why does getting them wrong take a whole site offline?

What are nameservers?

A nameserver is a server whose job is to answer DNS questions about a domain, translating human-friendly names like example.com into the records computers need, most famously the IP address behind an A or AAAA record. When people ask what are nameservers, the shortest honest answer is: they're the authoritative source of truth for your domain's DNS records.

Every domain delegates responsibility to a set of nameservers, usually two or more for redundancy. You've seen their names: things like ns1.cloudflare.com or dns-a.example-host.net. Those aren't decoration. They tell the entire internet which servers to ask whenever someone needs to reach anything at your domain, mail servers, web servers, subdomains, all of it.

Authoritative vs. recursive: two different jobs

It helps to separate two roles that both get loosely called 'DNS servers.' An authoritative nameserver holds the actual records for a zone and gives the definitive answer. These are your domain's nameservers. A recursive resolver, by contrast, holds no records of its own; it's the server your device asks (often run by your ISP, or a public one like 1.1.1.1), and its job is to go find the answer by querying other servers on your behalf and caching the result.

So your laptop asks a resolver, and the resolver does the legwork of tracking down your authoritative nameservers and asking them. You configure the authoritative side. The recursive side is what everyone else's devices use to reach you.

How a lookup actually flows

Say someone types example.com. Their resolver, if it hasn't cached the answer, starts at the top. It asks a root nameserver, which doesn't know example.com but does know who handles .com, and points to the .com TLD nameservers. The resolver asks those, and they return the NS delegation: the names of the authoritative nameservers you set for your domain. Finally the resolver asks one of your nameservers directly, which returns the A record. The resolver caches it for the record's TTL and hands the IP back.

This whole cascade usually finishes in tens of milliseconds. But it reveals why nameservers matter so much: they sit at the bottom of that chain as the final authority. If they're wrong, unreachable, or don't match what the registry has on file, the resolver never reaches a valid answer.

How a domain name resolves to a server

Where nameservers are set (and glue records)

There are two places DNS lives, and confusing them is the classic beginner mistake. Your registrar (where you bought the domain) controls which nameservers the domain delegates to. Your DNS host (which may be the same company, or Cloudflare, Route 53, etc.) controls the individual records inside the zone. Point your registrar at the wrong nameservers and it doesn't matter how perfect your A records are, nobody will ever ask that server.

One edge case worth knowing: glue records. If your nameservers are subdomains of the very domain they serve (ns1.example.com serving example.com), you have a chicken-and-egg problem, to find the nameserver you'd need to resolve the domain the nameserver is responsible for. Glue records break the loop by storing the nameserver's IP address directly at the registry level. Most people using a third-party DNS host never touch glue, but it explains delegation failures when you run your own.

Common nameserver problems

The failures cluster into a few types. Mismatched delegation: the NS records at your registry don't match what your DNS host expects, so resolvers get inconsistent answers. Lame delegation: a nameserver is listed as authoritative but doesn't actually serve the zone, silently dropping a fraction of queries. Propagation delay: after changing nameservers, old delegation can linger in caches for up to 48 hours because TTLs at the registry level are long. And plain outages: if all your nameservers share one provider and it goes down, your domain effectively vanishes.

You can inspect your delegation quickly with dig NS example.com +trace, which walks the whole path from the root down and shows exactly which servers answer at each step, or check the current records with our DNS checker. If the NS set returned by the parent zone matches your DNS host, delegation is healthy.

Why nameservers deserve monitoring

Because nameservers change so rarely, nobody watches them, which is exactly why an accidental edit, a lapsed DNS-hosting account, or a provider outage can quietly take a domain down and go unnoticed until customers complain. A domain with only one working nameserver still resolves most of the time, masking the problem until the day it doesn't.

VigilDog's DNS and domain monitoring tracks your nameservers and records from the outside and flags drift, unexpected changes, or delegation that no longer resolves, so a silent DNS change becomes an alert instead of an outage. If you manage domains for clients, it's the difference between spotting a problem and explaining one.