NS record
Every record so far in this module has been about data attached to a name — an address, a mail server, an alias, arbitrary text. An NS record is different in kind: it doesn't describe the domain itself so much as it names who's allowed to answer questions about it at all.
What it stores
An NS record names one of the authoritative name servers for a zone:
A domain typically publishes several NS records, not one — redundancy here matters more than almost anywhere else in DNS, because if every authoritative server for a zone is unreachable at once, every record in that zone becomes unresolvable for anyone whose cache has expired, no matter how correct those records are.
Delegation: how a parent zone hands off a child zone
DNS is a hierarchy, and NS records are the mechanism that hierarchy is built from. The .com zone doesn't know anything about example.com's A records, its MX records, or anything else it hosts — it only knows which name servers to point a resolver at for example.com specifically:
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.
Querying a .com root-level server directly (@a.gtld-servers.net is one of the servers authoritative for .com itself) doesn't return an A record or anything about example.com's content — it returns exactly this: a referral, telling the resolver which servers to ask next. This is delegation: the parent zone doesn't answer for the child, it points at whoever does. That handoff, repeated at each level from the root down, is the entire structural mechanism the DNS hierarchy runs on — this article isn't the place to walk the full recursive lookup step by step, since that process gets its own dedicated treatment later in the course, but the delegation NS records perform is the piece that makes that later walk possible at all.
Two separate copies of a zone's NS records exist, and they're expected to match:
- At the parent (
.com, in this example) — configured through whatever registrar sold the domain, since the registrar is what actually talks to the parent zone's operator. - At the zone itself — an NS record at
example.com's own apex, inside its own zone file, alongside theSOArecord every zone apex carries.
Nothing forces these two copies to agree, and when they don't, resolvers get inconsistent answers depending on which set of servers they end up asking — a state called lame delegation, covered in the scenario below.
Glue records: breaking a circular dependency
A subtler problem shows up when a zone's own name server lives inside that same zone — ns1.example.com serving example.com, exactly as in the examples above. Resolving ns1.example.com to an IP address normally means querying example.com's name servers. But ns1.example.com is one of example.com's name servers. Without help, a resolver would need ns1.example.com's address to ask ns1.example.com what its own address is.
The parent zone breaks that circle by publishing a glue record — the child name server's A record, attached directly to the delegation at the parent, so the address ships alongside the referral instead of requiring a separate lookup that can't yet succeed:
;; ADDITIONAL SECTION:
ns1.example.com. 172800 IN A 198.51.100.53
ns2.example.com. 172800 IN A 198.51.100.54
Glue is only required when a name server's name falls inside the zone it serves — an in-bailiwick name server, in the RFC's terminology. A domain using ns1.dns-provider.net as its name server needs no glue at all: that name resolves through dns-provider.net's own zone, an entirely separate, already-resolvable chain with no circular dependency to break.
Practical scenario: a domain resolves — sometimes
A site works fine for most visitors but fails intermittently for others, with no pattern tied to location or ISP — just inconsistent, unpredictable failures. Querying the registrar's listed name servers directly for the zone turns up the mismatch:
The registrar (the parent-zone delegation) lists ns1 and ns2. The zone's own apex NS record — what ns1.example.com itself actually serves — lists ns1 and ns3. ns2 was decommissioned months ago and no longer answers at all; ns3 was brought up as its replacement, but only the zone's own records were ever updated, not the delegation at the registrar. A resolver whose cache still points at ns2 gets nothing back — a lame delegation, a name server listed as authoritative that isn't actually serving the zone (or isn't serving it correctly) — and depending on which of the two authoritative-seeming name servers a given resolver happens to try, it either succeeds or times out.
The fix is updating the registrar's delegation to match the zone's real, current server list — both copies have to agree, and after a change like this, propagation follows the same TTL-bound caching rules covered in Introduction to DNS.
Common mistakes
- Decommissioning a name server without updating the parent's delegation. The zone's own NS records can be perfectly correct while the registrar still points resolvers at a server that's gone, producing exactly the intermittent failures in the scenario above.
- Assuming glue is always required. It's only needed when a name server's name resolves through the very zone it serves; a name server hosted under a different, already-resolvable domain needs no glue record at all.
- Treating a "no answer" from one authoritative server as the whole zone being down. With multiple NS records in play, one lame or unreachable server can coexist with others that answer correctly — the fix is fixing the mismatch, not assuming the domain itself is broken.
Practice exercises
- Run
dig <a-real-domain> NS +short, then query each returned name server directly withdig <domain> NS @<name-server>and confirm all of them report the same set of authoritative servers. - A colleague argues that every name server needs a glue record, no exceptions. Using the in-bailiwick distinction above, explain when that's true and when it isn't.
Delegation is about which servers answer for a zone. There's one more record that describes the zone itself rather than anything inside it — who administers it, what version of it a server is holding, and, most consequentially, how long the internet is allowed to remember that a name in it doesn't exist.