What is an NS record and how does DNS delegation work?

Sajjad
DNS
10 Oct, 2026

An NS (Name Server) record is a DNS record that names the servers holding the authoritative data for a zone. NS records are what make delegation possible: the .com zone contains NS records saying which nameservers are responsible for example.com, and resolvers follow those records down from the root until they reach a server that can actually answer the question. In short, NS records are the signposts that connect every zone in DNS to its parent.

Every domain you own depends on NS records, even if you've never edited one directly, because your registrar publishes them in the parent zone when you choose a DNS provider. In this article you'll learn what an NS record contains, how delegation works from the root down, the difference between the NS records in the parent and those in your own zone, how to delegate a subdomain to a different provider, how to inspect delegation with dig, and the mistakes that cause hard-to-diagnose resolution failures.

What an NS Record Looks Like

An NS record maps a zone name to the hostname of a nameserver:

example.com.    86400    IN    NS    ns1.example-dns.net.
example.com.    86400    IN    NS    ns2.example-dns.net.

example.com.: The zone being described.
86400: The TTL. NS records usually have long TTLs, often a day or two, because they change rarely.
NS: The record type.
ns1.example-dns.net.: The hostname of an authoritative nameserver for the zone.

A few rules apply to NS targets:

They must be hostnames, not IP addresses. The IP address comes from the nameserver's own A or AAAA record.
They must not be CNAMEs. RFC 2181 requires NS targets to be canonical names that resolve directly to addresses.
You should have at least two, ideally on separate networks, so the zone stays reachable if one server fails. RFC 2182 covers this in detail, and most registries enforce a minimum of two.

How DNS Delegation Works

DNS is a tree. The root zone sits at the top, top-level domains such as .com and .uk sit below it, and your domain sits below its TLD. Each level doesn't store the data for the levels beneath it. Instead, it delegates them, using NS records to say "ask these servers instead".

When a resolver with an empty cache looks up www.example.com, delegation plays out like this:

Ask a root server: The resolver asks a root server for www.example.com. The root doesn't know the answer, but it returns a referral: the NS records for com. and the addresses of those servers.
Ask a .com server: The resolver repeats the question to a .com server. It returns another referral with the NS records for example.com..
Ask the authoritative server: The resolver asks one of the example.com nameservers, which returns the actual A record for www.example.com with the AA (authoritative answer) flag set.
Cache everything: The resolver caches the referrals as well as the answer. The next lookup for anything under example.com can skip straight to step 3.

The important thing to notice is that the root and .com servers never had the answer. They only knew who to ask next. That's delegation, and NS records are how it's expressed.

Seeing Delegation With dig +trace

You can watch the whole process with dig +trace, which performs the lookup itself starting at the root:

dig +trace www.example.com A

Trimmed sample output:

.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 4 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN  NS  ns1.example-dns.net.
example.com.            172800  IN  NS  ns2.example-dns.net.
;; Received 245 bytes from 192.5.6.30#53(a.gtld-servers.net) in 20 ms

www.example.com.        300     IN  A   192.0.2.10
;; Received 60 bytes from 203.0.113.53#53(ns1.example-dns.net) in 18 ms

Each block is one step down the tree. The last line shows which server finally gave the answer.

Parent NS Records vs Child NS Records

A delegated zone's NS records exist in two places, and understanding the difference explains a lot of confusing behaviour.

	Parent side (delegation)	Child side (apex)
Where it lives	In the parent zone, such as `.com`	At the top of your own zone
Who controls it	The registry, updated through your registrar	You, through your DNS provider
Authoritative?	No. It's a referral, not authoritative data	Yes
Typical TTL for `.com`	172800 (2 days)	Whatever your provider sets
What it's used for	Getting resolvers to your servers in the first place	Confirming the set of nameservers once there

When you "change nameservers" at your registrar, you're changing the parent side. When you edit NS records in your DNS provider's dashboard, you're changing the child side. The two sets should match. If they don't, different resolvers may behave differently, because some prefer the parent's referral and others replace it with the child's authoritative set once they've reached your servers.

You can compare the two sets yourself. First, ask a .com server directly, without recursion:

dig @a.gtld-servers.net example.com NS +norecurse

The NS records appear in the AUTHORITY section rather than the answer section, because the .com server isn't authoritative for them:

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  ns1.example-dns.net.
example.com.        172800  IN  NS  ns2.example-dns.net.

Then ask one of your own nameservers:

dig @ns1.example-dns.net example.com NS +norecurse

;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        86400   IN  NS  ns1.example-dns.net.
example.com.        86400   IN  NS  ns2.example-dns.net.

This time the records are in the answer section and the aa flag is set. If the two lists differ, fix whichever side is wrong.

A Word on Glue

There's a chicken-and-egg problem when a zone's nameservers live inside the zone itself, such as ns1.example.com serving example.com. A resolver can't look up the address of ns1.example.com without first reaching the example.com servers. The parent solves this by publishing the nameserver's IP address alongside the referral, which is known as a glue record. If your nameservers are under a different domain, as with most hosted DNS providers, you don't need glue.

Delegating a Subdomain

Delegation isn't only for registered domains. You can delegate any subdomain to a different set of nameservers. This is useful when:

A different team or business unit manages its own DNS, such as eu.example.com.
A cloud platform needs to manage records automatically, such as delegating k8s.example.com to a cloud DNS zone used by ExternalDNS.
You want to test a new DNS provider on a small part of your namespace before moving everything.

In a Zone File

To delegate dev.example.com, add NS records for it in the parent example.com zone:

$ORIGIN example.com.
@           3600    IN    SOA   ns1.example-dns.net. hostmaster.example.com. (
                                2026101301 7200 3600 1209600 3600 )
@           3600    IN    NS    ns1.example-dns.net.
@           3600    IN    NS    ns2.example-dns.net.
www         300     IN    A     192.0.2.10

; Delegate dev.example.com to another provider
dev         3600    IN    NS    ns-a.example-cloud.net.
dev         3600    IN    NS    ns-b.example-cloud.net.

Once this is in place, the example.com servers stop answering for anything under dev.example.com. They return a referral instead. Any other records you had for names under dev in the parent zone are ignored, so move them into the new zone first.

Check the file and reload:

sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

With Terraform on Route 53

When both zones are in Route 53, Terraform can create the child zone and wire up the delegation in one go:

resource "aws_route53_zone" "parent" {
  name = "example.com"
}

resource "aws_route53_zone" "dev" {
  name = "dev.example.com"
}

resource "aws_route53_record" "dev_delegation" {
  zone_id = aws_route53_zone.parent.zone_id
  name    = "dev.example.com"
  type    = "NS"
  ttl     = 3600
  records = aws_route53_zone.dev.name_servers
}

The name_servers attribute contains the four nameservers Route 53 assigned to the child zone, so the delegation always matches.

Verifying a Subdomain Delegation

dig dev.example.com NS +short

ns-a.example-cloud.net.
ns-b.example-cloud.net.

Then confirm the new servers actually answer authoritatively:

dig @ns-a.example-cloud.net app.dev.example.com A +norecurse

Look for the aa flag. If you get REFUSED or a referral back up the tree instead, the child zone hasn't been created on that provider yet.

Checking Every Nameserver at Once

A quick loop checks that each of your nameservers responds and agrees on the SOA serial, which tells you whether they're serving the same version of the zone:

for ns in $(dig example.com NS +short); do
  printf '%-28s ' "$ns"
  dig @"$ns" example.com SOA +short +norecurse | awk '{print "serial " $3}'
done

ns1.example-dns.net.         serial 2026101301
ns2.example-dns.net.         serial 2026101301

An empty line or a timeout for one server means it isn't answering for your zone, and a different serial means it's out of date.

Common NS Record Problems

Parent and child NS sets don't match: Usually caused by changing nameservers at the registrar without updating the provider's NS records, or the reverse. Make both sides list the same servers.
A listed nameserver doesn't serve the zone: Known as a lame delegation. The server either doesn't respond or answers without authority. Resolvers waste time on it before trying another.
Only one nameserver: A single point of failure. Use at least two on independent infrastructure.
Pointing NS at an IP or a CNAME: Both are invalid. Use hostnames with A and AAAA records.
Forgetting about long TTLs: Parent NS records for .com are cached for up to two days. Changes to nameservers can take that long to reach every resolver, so keep the old provider serving the zone during the switch.
Leaving records behind after delegating a subdomain: Records for api.dev.example.com in the parent zone stop working once dev is delegated. Recreate them in the child zone.

FAQ: NS Records

An A record maps a name to an IPv4 address. An NS record names the servers that are authoritative for a zone. Resolvers use NS records to find out who to ask, then ask those servers for records such as A records.

At least two, and most providers give you between two and four. More servers on separate networks improve resilience, but there's little benefit beyond a handful.

At your domain registrar. The registrar sends the change to the registry, which updates the NS records in the parent zone. Your DNS provider's own NS records should then match.

Yes, as long as both providers serve identical zone data. That usually means one acts as primary and the other as secondary, or you push the same records to both with automation. DNSSEC adds extra coordination when doing this.

When you query a parent zone's server, such as a .com server, the NS records for your domain are a referral rather than authoritative data. DNS returns referrals in the authority section and only puts authoritative answers in the answer section.

Yes. Create the subdomain as its own zone on the new provider, then add NS records for the subdomain in the parent zone pointing at that provider's nameservers.

Conclusion

NS records are what connect the zones of DNS into a single tree: each one says which servers are responsible for a zone, and resolvers follow them from the root down to your own nameservers. Every domain has two copies, a referral in the parent zone controlled through your registrar and an authoritative set in your own zone, and the two should always match.

Once you understand delegation, you can use it deliberately, handing subdomains to other teams or platforms while keeping the main zone where it is. Use dig +trace and +norecurse queries to see exactly what each level of the tree says about your domain, and most delegation problems become straightforward to find and fix.