Nameservers and NS Records: How DNS Delegation Works

A nameserver is a server that answers DNS queries. More precisely, it is software listening for DNS questions ("what is the A record for example.com?") and returning answers. Which questions it can answer depends on which zones it has been made responsible for.

A zone is a slice of the DNS namespace that one set of nameservers manages — for example, all the records under example.com. When a nameserver holds the real records for a zone, it is authoritative for that zone, and its answers are the source of truth. Every domain needs at least one authoritative nameserver, and in practice several, so that the rest of the internet can find its records. See What is DNS? for how this fits into the wider system.

It helps to separate two very different jobs that both get called "nameserver":

• Authoritative nameserver: holds the actual zone data for one or more domains and answers questions about those domains directly. When you set up DNS for example.com, you are publishing records onto its authoritative nameservers.
• Recursive resolver: does not own any zone data. Instead it looks answers up on behalf of clients — walking the chain from the root down to the authoritative server, then caching the result so the next identical query is fast. The resolver your laptop or ISP uses is recursive.

So a recursive resolver is the one doing the legwork of a lookup, while authoritative nameservers are the ones that actually know the answer. Delegation, which the rest of this guide is about, is the mechanism a resolver follows to find the right authoritative server.

An NS record ("name server") names an authoritative nameserver for a zone. Its value is a hostname — for example ns1.example.com — not an IP address.

NS records are how delegation happens. A parent zone publishes NS records that point to the authoritative nameservers of a child zone, effectively saying "I don't hold those records myself; ask these servers instead." That hand-off repeats down the tree:

1. The root zone delegates .com by publishing NS records for the .com nameservers.
2. The .com TLD zone delegates example.com by publishing NS records pointing to your domain's authoritative nameservers, such as ns1.example.com and ns2.example.com.
3. Those authoritative nameservers answer for everything inside example.com — its A, AAAA, MX, TXT, and other records.

A recursive resolver follows this chain on every cold lookup: root → TLD → your domain. Each step is a delegation made of NS records.

Confusingly, a domain's nameservers are recorded in two places, and the two must agree.

• At the registrar (the parent side): when you register or manage a domain, you tell your registrar which nameservers are authoritative. The registrar passes that to the TLD's registry, which publishes the matching NS records in the parent zone (e.g. in .com). This is the delegation that resolvers actually follow.
• In the zone itself (the child side): at the apex of example.com there is also a set of NS records, served by the authoritative nameservers themselves. These are sometimes called the "in-zone" or apex NS records.

Best practice is that the parent's NS records and the zone's apex NS records list the same nameservers. When they disagree, you get hard-to-diagnose behavior: the delegation sends resolvers to one set of servers while the zone advertises another. Whenever you change DNS providers, update both — the registrar/parent delegation is the one that matters most for reachability.

There is a chicken-and-egg problem when a domain's nameserver lives inside the domain it serves. Suppose example.com is delegated to ns1.example.com. To look up ns1.example.com's IP address, a resolver would need to query the nameservers for example.com — but those are ns1.example.com. It cannot resolve the nameserver without already being able to reach the nameserver.

Glue records solve this. Alongside the NS records, the parent zone (the TLD) also publishes the nameserver's IP address as an A and/or AAAA "glue" record — for example, telling resolvers that ns1.example.com is at 198.51.100.53 (and perhaps 2001:db8::53 over IPv6). That IP is supplied directly in the delegation, so the resolver can reach the nameserver without a separate lookup.

You only need glue when the nameserver hostname is within the domain it serves. If example.com were delegated to nameservers under a different domain — say a DNS provider's ns1.dnsprovider.net — no glue is required, because that hostname is resolved through its own independent delegation. You normally configure glue (sometimes called "host records" or "child name servers") at your registrar.

You almost never want a single nameserver. The convention of primary and secondary nameservers exists for resilience: the primary holds the master copy of the zone, and secondaries pull a copy (a "zone transfer") and serve the same answers. To a resolver they are interchangeable — all of them are authoritative.

The practical rule is to run at least two nameservers, ideally on diverse networks, in different locations, and on different infrastructure. If ns1.example.com goes offline, ns2.example.com keeps answering and your domain stays reachable. Spreading nameservers across networks protects you from a single outage, route problem, or DDoS taking your whole domain dark. Most TLD registries require a minimum of two nameservers for exactly this reason.

Moving to a new DNS host means changing the nameservers your domain is delegated to. The safe sequence is: set up the full zone on the new provider first, confirm it serves the right records, then update the nameservers at your registrar so the parent delegation points to the new servers.

The change is not instant. Resolvers cache the existing delegation according to its TTL, and the TLD's NS records often have long TTLs (a day or two). Until those caches expire, some resolvers still send queries to your old nameservers — so you should keep the old zone serving correct records during the transition. For the full picture of caching and timing, see TTL and propagation. Plan nameserver moves with a window of hours to a couple of days, not minutes.

A domain's nameservers are part of its registration data, so they show up in WHOIS and RDAP. When you look up a domain on who.is WHOIS, the record lists the nameservers the registrar has on file — the same nameservers that drive the parent delegation.

That makes WHOIS a quick sanity check: the nameservers listed there should match the NS records you actually intend to use and the ones published at your domain's apex. A mismatch in WHOIS is often the first visible sign that a nameserver change is half-finished or that a delegation is pointing somewhere stale.

Most nameserver issues come down to a handful of recurring mistakes:

• Lame delegation: a nameserver is listed in the delegation but doesn't actually answer authoritatively for the zone (it's offline, misconfigured, or never had the zone loaded). Resolvers may try it, time out, and slow everything down — or fail intermittently.
• Mismatched parent and child NS records: the registrar/parent delegation lists one set of nameservers while the zone's apex lists another. This causes inconsistent resolution and breaks tools and validators that expect them to agree.
• Single point of failure: only one nameserver, or two nameservers on the same network or provider. One outage takes the whole domain down.
• Missing or stale glue: in-domain nameservers with no glue records, or glue pointing at an old IP, so resolvers can't reach the nameservers at all.

To see which nameservers are authoritative for any domain, use the who.is nameserver lookup. It shows the delegated nameservers and lets you find other domains that share a given nameserver — handy for spotting a provider's full footprint or confirming a migration.

For the registration-side view, run the domain through who.is WHOIS (or RDAP for the structured version), and check the nameservers there against what the nameserver lookup reports and what your zone publishes. To inspect the records those nameservers actually serve, use the DNS lookup. When all three agree, your delegation is healthy.