NS: nameserver

Who is authoritative for this zone. The NS record is the delegation primitive: it's what makes the DNS hierarchy a hierarchy. Every zone has NS records at its apex; parent zones publish NS records to delegate child zones.


Type number	2
RFC	1035
RDATA	An FQDN: the name of a server authoritative for the zone

What it holds#

A nameserver name (not an IP). Multiple NS records mean multiple authoritative servers: at least two are required by best practice (RFC 2182 covers how to choose and place them), and registrars usually enforce a minimum.

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

The corresponding A/AAAA records for the nameservers themselves are glue records: see "Glue" below.

When to use it#

Automatically, at the apex of every zone you create. Most authoritative DNS servers provision apex NS records for whichever nameservers serve the zone.
To delegate a child zone: e.g., put NS records for customers.example.com in the example.com zone, pointing at the team that runs customers.example.com's authoritative servers. 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: the authoritative DNS server manages those for you and ties them to the running daemon. Hand-rolling apex NS is how you make a zone return inconsistent answers.
For aliasing: that is CNAME.

dig example#

dig isitdns.net NS +short

hera.ns.cloudflare.com.
coleman.ns.cloudflare.com.

nslookup -type=NS isitdns.net

Non-authoritative answer:
isitdns.net	nameserver = coleman.ns.cloudflare.com.
isitdns.net	nameserver = hera.ns.cloudflare.com.

NS record order is not significant. Resolvers may return the two nameserver names in any order, and that order can vary between queries and tools. If your output shows coleman before hera where the example shows hera first (or vice versa), that is normal.

Resolve-DnsName isitdns.net -Type NS

Name                                     Type   TTL   Section    NameHost
----                                     ----   ---   -------    --------
isitdns.net                              NS     86400 Answer     hera.ns.cloudflare.com
isitdns.net                              NS     86400 Answer     coleman.ns.cloudflare.com

# Walk the full delegation from the root
dig isitdns.net NS +trace

nslookup and PowerShell's Resolve-DnsName return the final answer only. dig +trace is the learning tool here: it walks . to net. to isitdns.net. showing each NS handoff. nslookup cannot do +trace.

+trace is the best way to see delegation in action: each hop shows which NS handed the query to the next level. See anatomy-of-a-query for the full walk-through.

DoH query (HTTPS)#

DoH is DNS-over-HTTPS (see dot-doh). The application/dns-json format lets you query a DoH resolver directly from curl:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=NS' \
  | jq .Answer

[
  {
    "name": "isitdns.net",
    "type": 2,
    "TTL": 86400,
    "data": "hera.ns.cloudflare.com."
  },
  {
    "name": "isitdns.net",
    "type": 2,
    "TTL": 86400,
    "data": "coleman.ns.cloudflare.com."
  }
]

application/dns-json is a Cloudflare/Google extension; it is not defined by RFC 8484 (which uses wire-format DNS in the request body). The dig +https flag that speaks RFC 8484 requires dig 9.18 or later.

nslookup cannot do DoH, DoT, or DoQ. On Windows 11, Resolve-DnsName uses the system-configured DoH resolver when the OS is set up for encrypted DNS; it does not accept a -DnsOverHttps parameter and you cannot aim it at an arbitrary DoH endpoint. To probe a specific DoH service, use the curl form above.

Glue records#

When example.com is delegated to ns1.example.net., a resolver needs the address of ns1.example.net to contact it. But that address lives in example.net's zone, which the resolver may not have visited yet. The classic chicken-and-egg.

The fix: glue records: A/AAAA records served by the parent zone alongside the NS, giving the resolver the address it needs to make the next call. You only need glue when the NS name lives inside the zone being delegated (an "in-domain" name server in RFC 9499 terms, often loosely called "in-bailiwick"). When the NS name lives in some other zone, no glue is needed. RFC 9471 requires the parent's servers to include all available in-domain glue in referrals, and to set the TC flag when it does not fit.

A zone delegated to out-of-bailiwick nameservers does not need glue at the apex. Sub-delegations to in-bailiwick nameservers do require glue, and most authoritative servers provision it automatically.

Gotchas#

Apex NS must match what the registrar publishes. If your zone's apex NS says ns1.example.com / ns2.example.com but the registrar's delegation says pdns.example.com / sdns.example.com, resolvers can get inconsistent answers depending on which authoritative they reach. Always audit both.
Lame delegation = an NS that does not actually serve the zone. Resolvers get a referral, contact the server, get REFUSED, fall back to the other NS: slow and brittle. Check for lame delegation by querying the NS directly for the SOA:

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

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

The serial (the third field) climbs with every zone change, so yours will differ. A REFUSED or SERVFAIL here would indicate a lame delegation. A valid SOA answer means the server is authoritative and serving the zone. Drop +short and the header proves it: an authoritative answer carries the aa flag and no ra, because authoritative servers answer from zone data and do not offer recursion.

NS records ARE part of zone data but the version in the parent zone (the delegation) is what resolvers see first. Resolvers check the child's apex NS once they arrive, and the two should agree. See delegations for how the parent-child handoff works.
Removing an NS that you are still publishing at the parent breaks delegation cleanly only after the parent removes it too. Cache lifetimes can drag this out for the TTL of the parent's NS records (two days at many TLDs: the .net servers publish this zone's delegation NS with a 172800-second TTL).