NS: nameserver

NS names a server authoritative for a zone. It is the delegation primitive: parent zones publish NS records to hand a child zone to the servers that run it.

In one line:

example.com.    NS    ns1.example.com.
└── this zone ┘ └type┘ └── is served by this nameserver

What it holds#

A nameserver name, not an IP. Multiple NS records mean multiple authoritative servers: RFC 2182 requires at least two.

example.com.   NS   ns1.example.com.
example.com.   NS   ns2.example.com.

When a nameserver's own name lives inside the zone it serves (an "in-domain" server in RFC 9499 terms), the resolver needs its A/AAAA record before it can ask it anything, and the parent zone carries a copy of that address: a glue record (RFC 1034 §4.2.1). RFC 9471 requires the parent to include all available in-domain glue in the referral, and to set the TC flag when it doesn't fit. A nameserver named outside the zone it serves needs no glue.

When to use it#

• At the apex of every zone (RFC 1034 §4.2.1).
• To delegate a child zone: put NS records for customers.example.com in the example.com zone, pointing at the servers that run customers.example.com. See delegations.
• For sub-delegation in reverse zones (RFC 2317: see the RFC 2317 note).

When not to use it#

• Almost never as a hand-rolled record at the apex of a managed zone: the platform writes those. Hand-rolling apex NS is how a zone starts returning inconsistent answers.
• For aliasing: that is CNAME.

dig example#

$ dig @1.1.1.1 isitdns.net NS

example.isitdns.net is a set of names inside the isitdns.net zone, not a zone of its own: there is no zone cut, so it has no NS records to query. The live example is the apex, isitdns.net.

NS record order is not significant: resolvers can return the two nameserver names in either order, and that order can vary between queries.

Gotchas#

• Apex NS must match what the registrar publishes. If the zone's apex NS says one pair of names and the registrar's delegation says another, resolvers get inconsistent answers depending on which authoritative they reach.
• Lame delegation is an NS that does not actually serve the zone. The resolver gets a referral, contacts the server, gets no authoritative answer, and falls back to the next NS (RFC 9499 §7): slow and brittle. Check by querying the NS directly for the SOA:

dig -4 @coleman.ns.cloudflare.com isitdns.net SOA +short

coleman.ns.cloudflare.com. dns.cloudflare.com. 2412230330 10000 2400 604800 1800

The serial (third field) climbs with every zone change, so a live query returns a different number. A REFUSED or SERVFAIL here means lame delegation; an SOA with the aa flag (drop +short to see it) means the server is authoritative for the zone (RFC 1035 §4.1.1).

• NS records are part of zone data, but the parent's copy is what resolvers see first. They check the child's apex NS once they arrive, and the two should agree. See delegations for how the handoff works.
• Removing an NS still published at the parent only breaks delegation cleanly after the parent removes it too. The parent's NS record TTL sets how long that can take.

See also#

• DoT and DoH: encrypted DNS transport
• Query types
• All record types: cheat sheet