NS Record: syntax, examples, and troubleshooting

What does an NS record do?

NS is record type 2 from RFC 1035, and it is the record that makes DNS a distributed system rather than one enormous file. It says: *for this zone, ask these servers*. A recursive resolver starting from scratch queries a root server, is referred by NS records to the .com servers, is referred again by NS records to your domain's nameservers, and only then gets a real answer.

Every zone must have at least one NS record at its apex, and in practice registries require at least two on distinct hosts. NS records also create sub-delegations: publishing NS records at internal.example.com hands that entire subtree to a different set of servers, which is how large organizations split DNS responsibility across teams. Each such delegation creates a new zone with its own SOA record.

NS syntax and fields

Parent delegation vs the authoritative set

This distinction is the source of most confusing NS behaviour, so it is worth being precise. Two copies of the NS set exist:

• The parent-side delegation. NS records published in the parent zone (.com for example.com). These come from your registrar, which pushes them to the registry. They are what a resolver actually uses to find your zone the first time, and they appear in the *authority* section of a referral, not the answer section.
• The child-side authoritative set. NS records inside your own zone, served by your own nameservers. These are authoritative — they are the real answer to dig example.com NS once a resolver is already talking to your servers.

These are updated through completely different channels. Changing your zone's NS records in your DNS provider's panel does not change the registrar delegation, and changing nameservers at your registrar does not edit the records inside the zone file. When you migrate DNS providers you generally need to do both, and forgetting one is the classic half-migration.

Lame delegation

A delegation is "lame" when the parent points at a server that is not authoritative for the zone — it does not have the zone loaded, refuses the query, or answers without the AA flag. Symptoms are intermittent: resolvers that happen to try a working server succeed, resolvers that try the lame one get SERVFAIL or a long timeout. Users report that the site "works sometimes", which is why lame delegations survive for weeks.

The related and equally common problem is a parent/child mismatch: the registrar lists ns1.old-provider.net and ns2.old-provider.net, while the zone itself lists ns1.new-provider.com and ns2.new-provider.com. Resolvers use the parent delegation to find your servers, so the parent copy is the one that determines reality. If the old provider still serves a stale copy of the zone, you get answers — just the wrong ones. This is a leading cause of the symptoms in Why is my DNS not propagating? and of mail breaking after a nameserver change, covered in Mail bouncing after a DNS change.

Glue records

A chicken-and-egg problem appears when a zone's nameservers live inside the zone they serve. To resolve ns1.google.com you must ask the servers for google.com, which are ns1.google.com. The parent breaks the loop by publishing glue: A and AAAA records for the nameserver hostnames, served alongside the delegation in the additional section.

# Ask a .com server for the delegation, and look at the additional section
dig +noall +authority +additional @a.gtld-servers.net github.com NS

Practical consequences of glue:

• Glue is only required when the nameserver hostname is inside the zone it serves ("in-bailiwick"). Using ns-520.awsdns-01.net for example.com needs no glue, because .net can resolve it independently.
• Glue lives at the registry and is created through your registrar, usually as a "host record", "child nameserver", or "register nameserver" operation. Editing an A record inside your zone does not update glue.
• Stale glue is nasty. If you renumber a self-hosted nameserver and update the in-zone A record but not the registry glue, resolvers keep being handed the old address by the parent for as long as the delegation TTL allows — often 48 hours.
• If you use a managed DNS provider, you will never touch glue. It only matters when you run your own nameservers on your own domain.

TTL guidance

Delegation TTLs are long by convention — TLD registries typically publish delegations with a 172800 (48-hour) TTL, and you do not control that value. This is why a nameserver change is the slowest DNS change you can make, and why it is not comparable to changing an A record — see How long does DNS propagation take? for the full picture. Inside your own zone, matching the parent's intent with a long TTL (86400) is sensible; NS records should not change often, and a long TTL adds resilience.

Common NS mistakes

• Changing nameservers at the registrar without copying the zone first. The new provider starts with an empty or default zone and every record disappears. Export and import before you switch delegation, not after.
• Parent and child NS sets that disagree. Fix by making them identical. Some registries and DNSSEC tooling will actively complain.
• Only one nameserver. Most registries require two, and a single server is a single point of failure for your entire domain.
• Both nameservers on the same host or subnet. Two names pointing at one machine gives you the paperwork of redundancy and none of the substance.
• Pointing NS at a CNAME. Prohibited. NS targets must be hostnames with address records.
• Pointing NS at an IP address. The RDATA is a name, not an address. Provider forms that accept an IP produce a broken delegation.
• Deleting the old provider's zone immediately after cutover. See the TTL note above.
• Forgetting DNSSEC during a migration. If the zone is signed, the DS record at the parent must be updated in step with the nameserver change, or validating resolvers will return SERVFAIL. Check with the DNSSEC checker before and after.

Check it with dig

# The child-side authoritative NS set
dig +short google.com NS

# The parent-side delegation, straight from a .com server
dig +noall +authority @a.gtld-servers.net google.com NS

# Walk the delegation from the root and watch every referral
dig +trace google.com

# Confirm a specific server is authoritative — look for the "aa" flag
dig @ns1.google.com google.com SOA | grep flags

# Does each nameserver hostname actually resolve?
for ns in $(dig +short google.com NS); do echo "$ns -> $(dig +short "$ns" A)"; done

Confirm the registrar side with a WHOIS lookup, which reports the nameservers on file at the registry, and check the zone's serial across servers with the SOA lookup — a serial that differs between nameservers means one of them has not received your latest change.