Nameservers, Delegation and DNS Providers Explained

One lookup, followed from the top

When someone opens www.example.com, a recursive resolver, usually run by their ISP or a public DNS service, does the following if it has nothing cached:

1. It asks a root server where .com is handled. The root answers with a referral to the .com registry's nameservers.
2. It asks a .com nameserver about example.com. The registry does not know the website's address, but it holds a list of NS records for example.com, which is a referral to the domain's own nameservers.
3. It asks one of those nameservers for www.example.com. This nameserver is authoritative and returns the final answer, an A or AAAA record or a CNAME.

Two different sets of data are therefore involved. The registry holds the delegation (which nameservers are in charge). The nameservers hold the zone content (what the records actually say). A domain owner controls the delegation through a registrar, and controls the zone content at whichever provider runs the nameservers. Confusing the two is the main source of mistakes during migrations.

Reading delegation with dig

You can see both levels yourself:

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

The first walks the chain from the root. The third asks the .com servers directly and shows the delegation as the registry publishes it, which is the version that matters for being "live". Compare it with what the domain's own nameserver says; a mismatch means a pending change or a misconfiguration.

NS records, glue and the chicken-and-egg problem

NS records name servers, not addresses. If the nameserver for example.com is called ns1.example.com, a resolver needs to know the address of ns1.example.com to ask it a question, but to find that address it has to ask the nameserver for example.com. The loop is broken by glue records: A and AAAA records for the nameserver that the parent zone publishes alongside the delegation.

example.com.      NS   ns1.example.com.
ns1.example.com.  A    192.0.2.53       ; glue, published in the .com zone

Glue is only needed when the nameserver's name is inside the domain it serves. If you use hostnames from a provider, such as ns1.provider-dns.net, you do not create glue yourself. Using vanity nameservers that sit inside your own domain, which resellers and some hosting companies do, means you must register the host records with your registrar and keep their IP addresses current. Stale glue is a common cause of "my domain half-works" reports.

Best practice is at least two nameservers on separate networks. Provider outages that take a domain offline are almost always the case of every nameserver being under one operator's control.

Registrar DNS versus third-party DNS

When you register a name, the registrar normally sets default nameservers that point at its own DNS. You are free to replace them with any provider's. The two models differ mostly in coupling, not in capability:

Question	Registrar's default DNS	Dedicated DNS provider (e.g. Cloudflare, Amazon Route 53, others)
Setup effort	None; works on registration	Create zone, copy records, change delegation
Coupling	DNS dies if you leave the registrar	Registrar and DNS are independent
Features	Basic records; varies a lot	Usually API access, traffic steering, analytics, more record types
Control	One login for everything	Two accounts to secure
Resilience	Depends on registrar's network	Often global anycast networks

No provider is universally better. Choose by what you need: Infrastructure as code, geographic routing, DNSSEC signing, uptime commitments and integration with your hosting. Splitting registrar and DNS has one persistent benefit: if either account is compromised or the registrar has an outage, you still hold half of the system. The cost is that one more login needs strong protection, including two-factor authentication.

Anycast and why big DNS providers look the same everywhere

Large DNS operators announce the same IP addresses from many data centres using anycast routing. A resolver in Hanoi and one in Frankfurt both reach the nearest location, so lookups are faster and a failure at one site shifts traffic to the next. The practical effect is that two nameservers from a provider can cover the world, which is why you will see providers give you exactly two nameservers. Anycast does not remove the need for redundancy at the provider level; the standard advice is still not to put every delegation under a single operator if downtime would be costly.

TTL: how long answers stay cached

Every DNS record carries a time to live (TTL), in seconds, that tells resolvers how long they may cache it. A low TTL speeds up changes and increases query volume. A high TTL reduces load and slows rollouts. Two TTLs matter in a migration:

• The TTL of the records in your zone, which you control at your DNS provider.
• The TTL of the NS delegation at the parent, which the registry sets. For many TLDs, this is long, often a day or two. Check with dig against the registry servers to see the exact value, and see WHOIS vs RDAP for how to read the status data that explains why a delegation might be missing.

The second is the real reason a nameserver change takes time to be noticed everywhere.

DNSSEC and the DS record

DNSSEC adds cryptographic signatures to DNS answers so that resolvers can detect tampering. The chain of trust is built by the parent publishing a DS record: a hash of the child zone's signing key. If the DS in the parent matches a key in your zone, validating resolvers trust the answers. If you change nameservers to a provider that signs with a different key and the old DS stays at the registry, validating resolvers will treat every lookup as an attack and return SERVFAIL. The domain looks completely down to many users while still working for some.

Switching nameservers without downtime

1. Export the zone from the old provider, or list every record manually, including MX, TXT (SPF, DKIM, verification records), SRV and CAA. Forgotten email records are the typical cause of silent breakage.
2. Lower the TTLs on important records a day or two beforehand.
3. Create the zone at the new provider and import the records. Do not touch the delegation yet.
4. Test the new nameservers directly, bypassing caches:

   dig @ns1.newprovider.example www.example.com A +short
   dig @ns1.newprovider.example example.com MX +short

   Compare answers to the old provider.
5. Handle DNSSEC as described above.
6. Change the NS records at your registrar to the new provider's names.
7. Keep the old zone alive for at least the parent NS TTL plus a margin, so resolvers that still have the old delegation get correct answers.
8. Verify with dig +trace and a few public resolvers, then restore longer TTLs.

Changing nameservers also affects email. If the destination zone is missing an MX or an SPF record, mail will fail for hours before anyone notices.

Propagation myths

• "DNS propagates worldwide for 24 to 48 hours." There is no push network. DNS is a cache system, and an update becomes visible when each resolver's cached copy expires. Many changes are visible within minutes; the delegation TTL at the parent sets the upper bound.
• "My domain is down because propagation is slow." Usually it is a configuration problem. Query the authoritative nameserver directly to find out.
• "Flushing my browser cache fixes propagation." Browser and operating system caches exist but the main cache is the resolver's.
• "A website tool says it is not propagated, so it is not." Propagation checkers query a handful of resolvers at one moment. They prove those resolvers' state, nothing more.

What nameservers reveal in zone file data

The delegation is public. In the zone files that the ICANN CZDS program distributes, every name appears with its NS records, which means you can see which DNS provider runs a very large number of domains without querying them one by one. Counting domains per nameserver suffix gives a view of the DNS provider market for a TLD. It is also a hint about hosting: the nameservers of many shared-hosting and website-builder companies identify the platform.

There are strong caveats. A domain's nameservers reflect who answers DNS, not who hosts the website or email. Many sites use one company for DNS and another for hosting. Nameserver data tells you nothing about the owner, either (for that, see expired domains for how ownership changes surface), and zone files do not include registration dates or prices.

Parking nameservers as a signal

Some nameservers belong to parking services, which return an ad page or a "for sale" page for any name delegated to them. A cluster of names delegated to such nameservers is a useful signal for analysts: the domains probably have no real website, and a sudden change from a normal provider to a parking nameserver sometimes follows expiry, as the domain lifecycle describes. A move onto parking nameservers is a weak clue and not proof of anything about ownership, since some owners use parking deliberately. The same dataset helps with spotting new infrastructure: a batch of names registered the same day that share unusual nameservers can be reviewed on a newly registered domains list, though a shared nameserver is a lead, not a verdict.

Frequently asked questions

What is the difference between a nameserver and an NS record?

A nameserver is the server that answers DNS queries for a zone. An NS record is the data entry, in the parent zone and in the zone itself, that names which servers are authoritative for the domain.

Do I need glue records?

Only when a nameserver's hostname is inside the domain it serves, such as ns1.example.com for example.com. Otherwise the parent does not need to publish an address because resolvers can look it up elsewhere.

Is it better to use my registrar's DNS or a third-party DNS provider?

Neither is universally better. Registrar DNS is simple but tied to that registrar; a dedicated provider offers more features and independence at the cost of another account to secure. Choose by features, redundancy and operational needs.

How long does a nameserver change take?

Often minutes to a few hours, but resolvers may keep the old delegation until its TTL expires, which for many TLDs can be a day or two. Keep the old zone serving correct data for that period.

Why does my site fail after changing DNS providers on a signed domain?

Probably a stale DS record. If the registry still holds a DS for the old provider's key, validating resolvers reject the new provider's answers. Remove or update the DS at the registrar.

Can nameservers tell me who hosts a website?

Not reliably. They show who answers DNS. Many sites use one provider for DNS and another for hosting. Nameserver patterns are a hint about platforms and parking, not a hosting or ownership record.