NS record
Generated by GPT-5-miniExpansion Funnel Raw 48 → Dedup 0 → NER 0 → Enqueued 0
| NS record | |
|---|---|
 | |
| Name | NS |
| Type | Delegation |
| Purpose | Specifies authoritative name servers for a DNS zone |
| Introduced | 1987 |
| Defined in | RFC 1034, RFC 1035 |
NS record
An NS record indicates which authoritative name servers are responsible for a DNS zone and is essential for domain name resolution across the Internet. It is used at zone apexes and delegation points to point resolvers to authoritative servers operated by organizations such as Internet Assigned Numbers Authority, Internet Engineering Task Force, Cloudflare, Amazon Web Services, and Google. NS records interact with resource records like A record, AAAA record, CNAME record, SOA record, and protocols including DNS over HTTPS and DNS over TLS.
Overview
NS records are specified in standards such as RFC 1034 and RFC 1035 and are fundamental to the operation of the Domain Name System hierarchy spanning root servers like a.root-servers.net and top-level domains managed by entities including Internet Corporation for Assigned Names and Numbers and various country-code registries. They function at delegation points between parent and child zones, appearing in both parent zone delegations and child zone apexes, and are used by resolvers implemented in software like BIND, Unbound, Knot DNS, PowerDNS, and Microsoft DNS Server.
Format and Function
An NS record maps a zone name to a hostname of an authoritative name server; that hostname itself must resolve via A record or AAAA record entries. The record is stored in zone files alongside SOA record metadata and uses the same textual representation in formats understood by tools such as dig, nslookup, and host. NS records do not include IP addresses directly; when a parent zone delegates to a child zone, it typically supplies glue records (A/AAAA) when the nameserver hostname is inside the delegated zone, which involves registries such as Public Interest Registry or DENIC during domain registration.
Delegation and Zone Management
Delegation requires coordination between registrars—examples include GoDaddy, Namecheap—and registries like Verisign or country-code operators. The parent zone lists NS records to point to child-zone nameservers; if those nameservers are in-bailiwick (inside the child zone), the parent must provide glue records to avoid circular resolution, a process enforced by registry policies and implemented by provisioning systems used by registrars and registry operators. Zone administrators use zone transfers (AXFR/IXFR) supported by servers such as BIND and PowerDNS and may employ secondary servers across providers like Amazon Route 53, Google Cloud DNS, and Microsoft Azure DNS for redundancy.
DNSSEC and Security Considerations
When DNSSEC is deployed—per standards like RFC 4033, RFC 4034, RFC 4035—NS records remain unsigned in isolation but are covered by the zone's DNSSEC chain of trust via signed zone data and DS records stored in the parent. Key management with DNSKEY and delegation signer records requires coordination with registrars and registries; mistakes in DS record submission can break validation enforced by resolvers such as Unbound or validating libraries like ldns. Operational security also involves protecting zone-transfer endpoints and TSIG keys defined in RFC 2845, and defending against attacks observed in incidents involving providers like Dyn and research disclosed at conferences such as Black Hat USA.
Common Issues and Troubleshooting
Common problems include mismatched NS sets between parent and child zones, missing glue records for in-bailiwick nameservers, and DNS propagation delays across recursive resolvers used by services like Google Public DNS and Quad9. Tools such as dig, nslookup, and online checkers maintained by organizations like ICANN or IETF working groups are used to diagnose inconsistencies, delegation failures, and DNSSEC validation errors. Misconfigurations at registrars (for example with Name.com or OVHcloud) or registry operator changes can lead to domain resolution outages and require coordination with support teams and incident response frameworks similar to those in major outages at Amazon Web Services or regional registry incidents.
Implementation and Examples
Zone file excerpt demonstrating an NS set for example.com in common syntax used by BIND and other servers: ; Zone apex records @ IN SOA ns1.example.com. hostmaster.example.com. ( 2026010101 7200 3600 1209600 3600 ) @ IN NS ns1.example.com. @ IN NS ns2.example.net.
Glue example when nameserver is in-zone: ns1.example.com. IN A 198.51.100.1
Command-line verification: dig NS example.com @a.root-servers.net dig +trace example.com
Operators often distribute authoritative servers across providers and locations—using platforms like Cloudflare, Amazon Route 53, Google Cloud DNS, and colocated servers at facilities run by Equinix or network operators participating in Regional Internet Registries—to achieve resilience, comply with registry policies, and ensure correct delegation.