An NS (Name Server) record is a DNS resource record that specifies which authoritative name servers are responsible for a domain zone. NS records delegate the domain from the parent zone down to the servers that hold every other record (A, MX, TXT). Without correct NS records a domain will not resolve, leaving the website and email unreachable.
This guide explains what an NS record is and how zone delegation works, how glue records differ from ordinary NS records, why primary and secondary servers matter, how to check a domain's NS with dig and WHOIS, how to change NS servers safely during a migration while accounting for TTL and propagation, and the mistakes that break delegation most often.
What Is an NS Record
An NS record links a DNS zone to the names of its authoritative servers. When you register a domain, the registrar publishes NS records in the parent zone (for example the .com zone), telling the whole internet: "these servers are authoritative for this domain." A resolver walks the chain from the root servers to the TLD, and from the TLD to your NS servers.
The NS record is defined in RFC 1035 (record type NS, code 2) and in the domain name architecture of RFC 1034. The value of an NS record is a server hostname (FQDN), not an IP address — which is exactly why glue records are sometimes required (see below).
Zone Delegation and the Parent Zone
Delegation is the handoff of responsibility for a domain or subdomain from a parent zone to a child. NS records exist in two places at once: in the parent zone (at the registrar / TLD) and inside the domain's own zone. Ideally both sets match. Resolvers use the parent zone to locate the servers, while the in-zone NS record confirms the delegation.
Glue Records
If a domain's authoritative server lives inside the delegated domain itself (for example the NS for example.com is ns1.example.com), you get a circular dependency: to learn the server's IP you must ask that very server. The fix is a glue record: the parent zone stores the A/AAAA address of such an NS right next to the delegation. Glue is only needed for in-domain name servers.
Primary and Secondary Name Servers
A domain usually has several NS servers for resilience. The primary (master) is the server where you edit the zone. Secondary (slave) servers receive a copy of the zone from the primary via zone transfer (AXFR/IXFR). To clients all NS servers are equal: a resolver may query any of them. Running at least two NS servers in separate networks is a best-practice requirement.
| Record | Purpose | Where it lives |
|---|---|---|
| NS | Delegates the zone to authoritative name servers | Parent zone and the zone itself |
| SOA | Zone parameters: primary NS, admin email, serial, TTLs | Only inside the zone |
| A / AAAA | Maps a hostname to an IPv4 / IPv6 address | Inside the domain zone |
| Glue (A/AAAA) | IP for an in-domain NS, breaks the circular dependency | In the parent zone |
How to Check a Domain's NS
There are two ways to check NS servers: query them directly through DNS, or look at the delegation data at the registrar via WHOIS. The first shows what the zone actually serves; the second shows what is published in the parent zone. A mismatch between them is a common source of trouble.
Checking With dig
The dig utility queries NS records directly:
dig NS example.com +short
ns1.example.com.
ns2.example.com.
# NS from the parent zone (TLD):
dig NS example.com @a.gtld-servers.net +norecurseThe +short flag strips extra output. Querying a TLD server (@a.gtld-servers.net) reveals the delegation in the parent zone — compare it with the answer served by the domain's own NS.
Checking With WHOIS
WHOIS shows the NS servers registered at the registrar:
whois example.com | grep -i "name server"
Name Server: NS1.EXAMPLE.COM
Name Server: NS2.EXAMPLE.COMFree Online Check
If you'd rather skip the terminal, use enterno.io's free DNS record check: enter a domain and get NS, A, MX, TXT and SOA in a single report. Registrar-side delegation data is easy to inspect with the WHOIS tool, which also shows the registration expiry and domain status.
How to Change NS Servers
Changing NS is needed when moving a domain to another DNS host or hosting provider. Order matters: deleting the old zone first and then switching NS creates downtime. The correct sequence minimizes disruption.
- Lower the TTL in advance. 24–48 hours before the move, reduce the TTL of NS records and key records (A, MX) to 300–600 seconds to speed up propagation.
- Build the zone on the new DNS. Copy every record (A, AAAA, MX, TXT, CNAME запись) to the new name servers before switching NS. Verify them against the current zone.
- Change NS at the registrar. In the registrar panel, replace the old NS with the new ones. The change propagates into the TLD parent zone.
- Wait for propagation. Propagation takes anywhere from a few minutes to 24–48 hours, depending on the delegation TTL at the TLD and resolver caches.
- Don't delete the old zone right away. Keep the old records live for at least 48–72 hours until every resolver has switched over.
TTL affects switch speed, but you don't control the delegation TTL in the parent zone directly — it's set by the TLD registry. So propagation can outlast the TTL of your own in-zone records.
For more on how the TTL value affects caching and propagation, read our DNS record TTL guide.
Common Mistakes
Errors in NS records lead to intermittent or total domain outages. Here are the most frequent ones.
NS Mismatch Between Registrar and Zone
A classic problem: the parent zone (at the registrar) lists one set of NS, while the zone itself serves another. Resolvers get contradictory data and some queries go to servers that don't exist. Always compare dig NS domain @TLD-server with dig NS domain answered by the servers themselves.
Lame Delegation
Lame delegation is when an NS record points to a server that is not authoritative for the zone or does not respond at all. The parent zone delegates the domain to a server that "doesn't know" about the zone. This increases response time and causes partial failures. Verify that each NS actually serves the zone's SOA record.
A Single NS Server
If a domain has only one NS, any failure of that server makes the domain unreachable. Standards and registrars require at least two NS, ideally in different subnets and data centers. Server types and roles are covered in detail in our article on DNS server types.
Typos in NS Names and Missing Glue
A typo in a name server's FQDN, or a missing glue record for an in-domain NS, breaks delegation. If a name server lives inside its own domain, you must configure a glue record at the registrar. The overall structure of resource records is explained in our overview of DNS record types.
Frequently Asked Questions
How does an NS record differ from an SOA record
An NS record lists the authoritative servers responsible for a zone and drives delegation. An SOA record describes the zone's own parameters: primary NS, admin email, serial number and refresh timers. There can be many NS records, but only one SOA record per zone. See details in our SOA record guide.
How many NS servers should a domain have
At least two NS servers — a best-practice requirement enforced by most registrars. Two or more servers provide resilience: if one is unreachable, a resolver queries another. Large zones use four or more NS placed across different networks and geographic locations for reliability.
How fast does an NS change propagate
An NS change usually propagates within a few hours, but full updates can take up to 24–48 hours. Speed depends on the delegation TTL in the parent TLD zone (set by the registry) and on ISP resolver caches. Lowering your TTLs in advance speeds things up but has no effect on the TLD-level TTL.
Are glue records always needed
No. Glue records are only needed when a name server sits inside the delegated domain itself — for example, the NS for example.com is called ns1.example.com. If you use an external provider's NS (ns1.hoster.net), glue is not required: their IP resolves through the provider's own zone.
Why is my site down after changing NS
Most often the cause is that records (A, MX) were not copied to the new NS before the switch, or the old zone was deleted too early. Also verify that the new NS already serves a correct zone. Use a DNS check to compare the answers of the old and new servers.
Can I check NS without the command line
Yes. Online tools like enterno.io's DNS record check show NS servers along with A, MX, TXT and SOA in a single report, no utilities to install. For registrar-side delegation data, use WHOIS.