Skip to content
Control Plane Labs

NS record

Names the authoritative nameservers for a zone, and creates delegations.

Last updated July 27, 2026

Zone-file example

; type 2, defined in RFC 1035
example.com.        86400   IN   NS   ns1.provider.net.
example.com.        86400   IN   NS   ns2.provider.net.
sub.example.com.    86400   IN   NS   ns1.other.net.   ; delegation to a child zone

Typical uses

  • Declaring which servers are authoritative for your zone
  • Delegating a subdomain to a different team, provider, or internal DNS
  • Migrating DNS providers by publishing both sets during a cutover
  • Splitting a zone so certificate automation can own only _acme-challenge

When it breaks, check

  • The NS set in the parent zone is what resolvers use; the copy inside your zone is only advisory
  • A mismatch between parent and child NS sets is 'lame delegation' and causes intermittent failures
  • Every listed nameserver must actually be authoritative and answer with the AA bit set
  • Long TTLs on NS records make provider migrations slow to take effect — lower them before you cut over

What the NS record does

NS records are how DNS becomes a distributed system. The root zone has NS records delegating com, the com zone has NS records delegating example.com, and your zone has NS records naming its own servers. A resolver walks that chain from the top.

The subtlety worth internalising is that two copies of your NS set exist: one in the parent zone, published by your registrar, and one inside your own zone. Resolvers follow the parent’s copy to find you. The in-zone copy is what your servers report once asked. When they disagree, resolution becomes non-deterministic in ways that are miserable to debug.

Zone-file and wire format

The syntax is zone TTL IN NS nameserver. — the RDATA is a domain name, never an address. If the named server lives inside the zone being delegated, the parent must also publish glue A/AAAA records so resolution can bootstrap; otherwise resolvers would need to resolve a name inside a zone they cannot yet reach. NS TTLs are conventionally long, often a day, because delegations rarely change.

; the zone's own NS set
example.com.         86400   IN   NS   ns1.provider.net.
example.com.         86400   IN   NS   ns2.provider.net.

; delegating a subdomain elsewhere: NS records in the PARENT zone
internal.example.com.  86400 IN   NS   ns1.internal.example.com.
; ...plus glue, because that nameserver is inside the delegated zone
ns1.internal.example.com. 86400 IN A   198.51.100.5

Common uses

Delegation is the interesting use. Splitting off a subdomain lets a different team, cloud account, or internal DNS system own it without giving anyone write access to the parent zone. It is also the safest pattern for certificate automation: delegate _acme-challenge.example.com to a tiny zone whose credentials live only in your ACME client, and a compromise of that client cannot touch production records. During a provider migration you publish both providers’ NS records, wait out the TTL, then remove the old set.

Troubleshooting

Start every DNS mystery by comparing the parent and child NS sets. Ask the parent’s servers what they delegate, then ask each listed nameserver what it thinks it serves, and check that each answers authoritatively. A server listed in the delegation that does not answer for the zone is a lame delegation: resolvers will still try it, time out, and retry elsewhere, producing latency spikes that look random.

Before any migration, drop the NS TTL well in advance. A 172800-second TTL means two days of unpredictable split behaviour after a cutover.

# what the parent zone delegates (authoritative view)
dig @a.gtld-servers.net example.com NS +noall +authority

# what the zone itself claims
dig @ns1.provider.net example.com NS +noall +answer

# confirm every listed server answers authoritatively (look for "flags: ... aa")
for ns in ns1.provider.net ns2.provider.net; do
  dig @"$ns" example.com SOA +noall +comments | grep -E 'flags|status'
done

The defining RFC

NS is type 2, defined in RFC 1035 §3.3.11, with the delegation model itself described in RFC 1034 §4.2. The requirement that the parent and child NS sets agree, and the classic operational failures when they do not, are covered in RFC 2181 §5 and RFC 1912 §2.8. Inspect a delegation with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types