NS record

An NS record tells the DNS tree which servers are authoritative for a zone. Every zone has at least two, usually more. When a resolver starts walking down from the root to answer a query, it follows NS records at every step: root to .com, .com to example.com, and so on.

Type code 2, defined in RFC 1035 §3.3.11. The delegation model (zone cuts, glue, authoritative data) is in RFC 1034 §4.2.

What it is

A name-to-hostname mapping where the hostname is a name server.

example.com.  86400  IN  NS  ns1.example.com.
|              |     |   |   |
|              |     |   |   └─ name server hostname (must resolve to A/AAAA)
|              |     |   └─ record type (NS = type 2)
|              |     └─ DNS class
|              └─ TTL
└─ owner name (the zone being delegated)

Delegation

Two zones always carry NS records for your domain: the parent zone (.com, at the registry) and your child zone (at your DNS provider). Same hostnames on both sides, but they come from different servers and behave differently.

Delegation across a zone cutparent and child each hold NS

parent zone

.com (at the registry)

example.com. NS ns1.example.com.

example.com. NS ns2.example.com.

These are not authoritative. The registry's answer carries the AA=0 flag and points the resolver at the child.

referral

→

go ask ns1 or ns2

child zone (authoritative)

example.com (at your DNS provider)

example.com. SOA ns1.example.com. ...

example.com. NS ns1.example.com.

example.com. NS ns2.example.com.

These answers carry AA=1. This is the source of truth.

The parent NS set and the child NS set must name the same hosts. When they drift (after a DNS migration you forgot to complete at the registrar), resolvers get inconsistent answers.

When a resolver walks down from root and hits .com, it gets a referral: "I'm not authoritative for example.com, go ask these nameservers." The AA bit is zero. When the resolver asks the listed nameserver, it gets an authoritative answer with AA=1. The child is the source of truth.

The parent and the child must name the same hosts. When they drift (someone migrated to a new DNS provider but never told the registrar), resolvers receive inconsistent answers depending on their cache state.

Glue records

Classic chicken-and-egg problem: the NS for example.com is ns1.example.com. To resolve ns1.example.com, the resolver needs to query example.com's nameservers, which include ns1.example.com. Infinite loop.

A glue record is the A or AAAA of the nameserver published by the parent, alongside the delegation. The registry serves the glue in the additional section of its referral response, so the resolver has everything it needs to contact the nameserver without another lookup.

Glue is required when the nameserver lives inside the zone it serves (in-bailiwick). It is not needed, and should not be published, when the nameserver lives elsewhere. Most DNS providers handle this automatically when you set up delegation.

What the hostname reveals

The NS hostname is one of the most reliable provider fingerprints in the DNS. Each DNS operator uses its own naming scheme.

NS provider patternswho runs the zone

ns*.cloudflare.comCloudflareanycast, 300+ PoPs

ns-*.awsdns-*.{com,net,org,co.uk}AWS Route 534 TLDs per delegation set on purpose

ns-cloud-*.googledomains.comGoogle Cloud DNSor ns*.google.com for legacy

*.azure-dns.{com,net,org,info}Azure DNSalso 4 TLDs

dns*.p*.nsone.netNS1pxx = tier; enterprise DNS

a.dnsimple.com, b, c, dDNSimplesingle letters

ns*.dnsmadeeasy.comDNS Made Easyenterprise / legacy

ns*.hover.comHover (Tucows)registrar DNS

ns*.domaincontrol.comGoDaddyregistrar DNS

If the NS set is a mix of two different operators (for example, some ns*.cloudflare.com alongside some ns-*.awsdns-*.com), the zone is either in the middle of a migration or deliberately split across providers for redundancy.

Diversity and redundancy

RFC 2182 (BCP 16) sets the operational bar: at least three nameservers, geographically dispersed, on diverse network paths. Modern managed DNS services (Cloudflare, Route 53, Google Cloud DNS) give you this by default via anycast: a single hostname answers from hundreds of PoPs worldwide.

A zone served by one provider is cheap to run but has one single point of failure: that provider. High-value domains (banks, large SaaS, government) often use two different providers to avoid correlated outages. The October 2016 Dyn outage is the usual cautionary tale.

Common mistakes

NS target is a CNAME

Forbidden by RFC 2181 §10.3. NS must name a host with A/AAAA, not a CNAME.

parent and child NS sets do not match

Common after a provider migration. The registrar still lists the old NS, the new provider has a different set. Resolvers pick up one or the other depending on cache, and answers disagree. Always update the parent (at the registrar) to match the child.

only two NS at the same provider

Meets the spec but not the RFC 2182 recommendation. If your single provider has an outage, the zone is unreachable.

stale glue at the registrar

The registry holds glue records independently from your DNS provider. After a migration, the old glue can linger until you update it manually.

nameservers without IPv6

Not broken, but sub-optimal. Modern NS should be reachable over both IPv4 and IPv6. Most managed providers handle this automatically.

Check which provider hosts your zone, whether parent and child NS sets agree, and whether the set has enough diversity: scan your domain.