Guide
Understanding the DNS NS Record: Nameservers and Zone Delegation
Written By Nadeem Khan, WhoisFreaks Team Published: July 13, 2026, Last Updated: July 13, 2026
Guide
Written By Nadeem Khan, WhoisFreaks Team Published: July 13, 2026, Last Updated: July 13, 2026
When a resolver looks up a domain, it first has to learn which servers are allowed to answer for that domain. That is the job of the NS record. NS stands for name server, and an NS record names the authoritative name servers responsible for a DNS zone. Every other record a domain uses, its A, AAAA, MX, and TXT records, lives on the servers that the NS records point to, which makes the NS record the entry point to a domain's entire DNS configuration.
This section explains what an NS record holds, how it delegates a zone from a parent to a child, why almost every domain runs more than one name server, and how to read and check NS records with common tools. It builds on the resolution process covered earlier in the guide and sits alongside the A record section that precedes it.
The NS record was defined in the original DNS specifications, RFC 1034 and RFC 1035, published by Paul Mockapetris in 1987. Those documents replaced the flat HOSTS.TXT model with a distributed, hierarchical name space, and the NS record is the mechanism that makes that hierarchy work. It lets one set of name servers hand responsibility for a part of the tree to another set, so no single operator has to hold the whole internet's naming data.
An NS record identifies an authoritative name server for a DNS zone. It does not store an IP address, a mail route, or any content itself. Instead, it points to the name of a server that holds the zone's real records. A zone lists a set of NS records, one per authoritative server, and a resolver uses them to find the source of truth for every other record in that zone.
The NS record is DNS record type 2, and its format is defined in RFC 1035, Section 3.3.11. Its data field (RDATA) contains a single value: the fully qualified domain name of one authoritative name server. The record uses the standard Internet (IN) class, and to list several name servers a zone simply publishes several NS records under the same name.
Like every DNS record, an NS record carries a TTL that tells resolvers how long to cache it before asking again. NS records are often configured with relatively long TTLs because nameserver assignments change less frequently than host addresses. However, TTL values vary significantly between DNS providers and operators. When a name server change is planned, operators usually lower the NS TTL a day or two in advance, so the switch takes effect quickly once it is made.
A zone should never rely on a single name server. RFC 2182, the best current practice for secondary DNS servers, states that the DNS requires multiple servers for every delegated zone. Running at least two, ideally on separate networks, means that if one server or network path fails, resolvers can still reach another and the domain keeps resolving. Most registrars and DNS providers assign two to four name servers by default for this reason.
These record types are easy to confuse because they all appear in a zone, but each does a different job. An A record maps a hostname to an IPv4 address. A CNAME aliases one hostname to another. An SOA record holds administrative data for the zone, such as the primary name server and serial number. An NS record does something none of the others do: it names which servers are authoritative for the zone. One rule follows from this. An NS record must point to a real hostname with address records, never to a CNAME, a restriction stated in RFC 2181, Section 10.3.
| Record | What its value is | Purpose |
|---|---|---|
| NS | A name server hostname | Names the authoritative servers for a zone |
| A | An IPv4 address | Maps a hostname to an address |
| CNAME | Another hostname | Aliases one name to another |
| SOA | Zone admin fields | Holds primary server and zone metadata |
Delegation is what separates the NS record from every other record type. It is how authority for a part of the DNS tree is handed from one zone to another.
Resolution starts at the root. A resolver asks a root server for a domain like example.com, and the root refers it to the name servers for the .com top-level domain. The .com servers do not hold example.com's records either. They hold NS records that delegate example.com to its authoritative name servers, and they refer the resolver there. Only then does an authoritative server return the actual A, MX, or other records. This referral chain, followed through the glue records and NS records at each level, is what NS records make possible.
NS records exist at two places, and the distinction matters when troubleshooting:
If the parent delegation and the in-zone NS set disagree, resolution can become inconsistent depending on which resolver is asked. Keeping the two in sync is a basic health check for any domain.
A glue record is an A or AAAA record for a name server, stored in the parent zone alongside the delegation. It exists to break a circular dependency. When a domain's name servers sit inside the domain they serve, for example ns1.example.com acting as a name server for example.com, a resolver cannot look up the address of ns1.example.com without first reaching example.com's name servers, which is exactly what it is trying to find.
The parent zone breaks the loop by publishing the name server's IP address directly as glue, so the resolver can reach it and continue. Glue is only needed for in-bailiwick name servers, meaning those named inside the zone they serve. A domain that uses out-of-zone name servers, such as ns1.dns-provider.net, needs no glue, because that provider's address resolves through its own separate zone. For the full referral sequence that depends on glue, see the DNS resolution process section earlier in the guide.
In a zone file, an NS record follows the pattern name TTL class NS nameserver. The name is the zone the record applies to, the class is IN, the type is NS, and the value is a name server's fully qualified domain name ending in a trailing dot.
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.In the NS record example above, both records delegate example.com to ns1 and ns2, each with a TTL of 172800 seconds (two days). When the name servers sit inside the same domain they serve, as they do here, the parent zone must also publish glue records: A or AAAA records for ns1.example.com and ns2.example.com, so resolvers can reach the name servers without a circular lookup.
The WhoisFreaks DNS Lookup tool returns a domain's NS records along with its other record types, in clean JSON, XML, or raw format. It can retrieve current NS records and delegation data without requiring command-line tools.
Both nslookup and dig can query NS records from a terminal.
nslookup -type=NS example.com returns the name servers for the domain.dig NS example.com does the same with more detail, including query timing and the responding server. Add +short for just the name server names.For checking NS records across many domains or inside a script or pipeline, the DNS API returns the same data as parsed JSON at scale.
A change to a domain's NS records means authority for the entire zone has moved to different name servers. In routine cases that is a provider migration. In an attack, it can signal domain or registrar-account hijacking, where an attacker repoints the domain to name servers they control and takes over its web and email traffic. Stale or dangling delegation, where NS records still point to a provider a domain no longer uses, is a related risk that can enable subdomain takeover.
Because NS changes are high-signal, security and investigation teams track nameserver changes over time rather than only reading the current record. From the WhoisFreaks DNS database, which holds more than 17.1 billion DNS records across 6.3 billion hostnames collected continuously, a historical lookup can show when a domain's name servers changed and what they changed to, which is often the first pivot in mapping attacker infrastructure.