DNS NS Record Explained

NS (Name Server) records are the foundation of DNS delegation. They answer the question "which servers are authoritative for this domain?" Every domain on the internet has NS records, and without them, the domain cannot resolve. When your NS records are wrong or the nameservers they point to are unreachable, your entire domain goes offline -- website, email, APIs, everything.

This guide covers what NS records do, where they are stored, how to check and change them, and what goes wrong when they break. For the broader picture of DNS record types, see DNS Record Types Explained.

What NS Records Do

An NS record maps a domain name to the hostname of a nameserver that is authoritative for that domain. "Authoritative" means the nameserver holds the definitive DNS records for the domain and provides answers to queries about it.

example.com.    86400    IN    NS    ns1.dnsprovider.com.
example.com.    86400    IN    NS    ns2.dnsprovider.com.

This tells the DNS system: "To find any DNS record for example.com, ask ns1.dnsprovider.com or ns2.dnsprovider.com."

Every domain has at least two NS records for redundancy. If one nameserver is unavailable, resolvers try the other. Most DNS providers assign two to four nameservers per domain.

Where NS Records Live

NS records exist in two places, and this distinction causes a lot of confusion.

At the Parent Zone (Delegation)

When you register a domain and set nameservers at your registrar, the registrar updates the parent zone (the TLD zone, like the .com zone) with delegation NS records. These records tell the DNS system which nameservers to query for your domain.

For a .com domain, the delegation NS records are stored in the .com TLD zone managed by Verisign:

;; In the .com TLD zone:
example.com.    172800    IN    NS    ns1.dnsprovider.com.
example.com.    172800    IN    NS    ns2.dnsprovider.com.

These delegation records are what make the whole system work. Without them, resolvers have no way to find your nameservers.

At the Authoritative Zone

Your nameservers also have NS records for your domain in the zone file itself:

;; In the example.com zone file:
example.com.    86400    IN    NS    ns1.dnsprovider.com.
example.com.    86400    IN    NS    ns2.dnsprovider.com.

These records should match the delegation NS records at the parent zone. If they do not match, you have a "lame delegation" problem, which is covered later in this article.

NS Records and Subdomain Delegation

One of the most powerful uses of NS records is delegating subdomains to different nameservers. This allows different teams or services to manage their own DNS independently.

;; In the example.com zone:
staging.example.com.    86400    IN    NS    ns1.otherservice.com.
staging.example.com.    86400    IN    NS    ns2.otherservice.com.

With this configuration, all DNS queries for staging.example.com and anything under it (like api.staging.example.com) are handled by otherservice.com's nameservers. The main example.com nameservers do not need to know about any records in the staging subdomain.

Common subdomain delegation scenarios:

• Development environments. Delegate dev.example.com to a development team's DNS provider.
• Separate services. Delegate status.example.com to a status page provider or blog.example.com to a content platform.
• Geographic regions. Delegate eu.example.com to nameservers in a European data center.
• Third-party vendors. Some SaaS platforms require subdomain delegation for custom domain features.

Checking NS Records

Using dig

# Query NS records for a domain
dig NS example.com

# Short output
dig NS example.com +short

# Check delegation at the parent zone
dig NS example.com @a.gtld-servers.net

The third command queries the .com TLD nameserver directly, showing you the delegation NS records at the parent zone level.

Using nslookup

nslookup -type=NS example.com

Verifying Consistency

To check that your delegation NS records match your zone NS records:

# Delegation NS (from parent zone)
dig NS example.com @a.gtld-servers.net +short

# Zone NS (from your nameserver)
dig NS example.com @ns1.dnsprovider.com +short

Both commands should return the same list of nameservers. If they differ, you have an inconsistency to fix.

For more lookup methods, see How to Check DNS Records and the nslookup Command Guide.

NS Record TTL

NS records typically have high TTL (Time to Live) values, often 86400 seconds (24 hours) or 172800 seconds (48 hours). High TTLs are appropriate because nameserver assignments change infrequently, and caching them widely reduces the load on parent zone servers.

The TTL for delegation NS records at the parent zone is set by the registry, not by you. For .com domains, the typical delegation TTL is 172800 seconds. The TTL for NS records in your zone file is set by your DNS provider and is usually 86400 seconds.

When you plan to change nameservers, the high TTL means caches around the world will hold the old nameserver assignment for up to 48 hours. This is why nameserver changes take time to propagate fully. For strategies to minimize propagation time, see DNS Propagation Explained.

Changing NS Records

Changing NS records at the domain level (updating which DNS provider handles your domain) is done at your domain registrar. You cannot change the delegation NS records through your DNS provider's interface.

The process:

1. Set up all DNS records at the new DNS provider.
2. Note the nameserver hostnames assigned by the new provider.
3. Log into your registrar and update the nameserver settings.
4. Wait for propagation (up to 48 hours).
5. Verify that both the old and new nameservers are serving correct records during the transition.

For subdomain delegation, you add NS records to your domain's zone file through your DNS provider's interface.

For the complete walkthrough, see How to Change Nameservers.

Common NS Record Problems

Lame Delegation

A lame delegation occurs when the NS records at the parent zone point to nameservers that do not have a zone configured for the domain. The resolver reaches the nameserver, but the nameserver responds with a REFUSED or SERVFAIL error because it does not know about the domain.

This happens when:

• You change DNS providers but do not update the NS records at your registrar.
• You remove your domain's zone from a DNS provider but leave the NS records pointing there.
• A nameserver is decommissioned but the NS records are not updated.

Fix: Update the NS records at your registrar to point to nameservers that actually host your zone.

Inconsistent NS Records

If the delegation NS records (at the parent zone) list different nameservers than the zone NS records (at your authoritative nameservers), resolvers may get confused. Some may follow the delegation and reach the correct server; others may cache inconsistent information.

Fix: Ensure that the NS records in your zone file match the nameservers you have registered at the registrar.

Single Nameserver

Running a single nameserver violates RFC 2182, which recommends at least two nameservers on different networks. If that single nameserver goes down, your entire domain becomes unreachable.

Fix: Always use at least two nameservers. Most DNS providers assign two to four by default.

NS Records Pointing to CNAMEs

NS records must point to hostnames that have A or AAAA records, not to CNAMEs. If an NS record points to a CNAME, the DNS resolution can fail because not all resolvers follow the CNAME chain when looking up nameserver addresses.

Glue Records

When your nameservers are under the domain they serve (vanity nameservers like ns1.example.com for the domain example.com), a circular dependency exists: to resolve example.com, you need the IP of ns1.example.com, but to resolve ns1.example.com, you need the NS records for example.com.

Glue records solve this by including the IP addresses of the nameservers directly in the parent zone's delegation response:

;; In the .com TLD zone:
example.com.        172800    IN    NS    ns1.example.com.
example.com.        172800    IN    NS    ns2.example.com.
ns1.example.com.    172800    IN    A     93.184.216.34
ns2.example.com.    172800    IN    A     93.184.216.35

The A records for ns1.example.com and ns2.example.com are glue records. They are set at the registrar alongside the NS records and break the circular dependency.

If your nameservers are not under your own domain (e.g., ns1.cloudflare.com for example.com), glue records are not needed because the nameserver hostnames can be resolved through their own domain's DNS.

References

1. RFC 1035, "Domain Names - Implementation and Specification," November 1987. https://datatracker.ietf.org/doc/html/rfc1035
2. RFC 2182, "Selection and Operation of Secondary DNS Servers," July 1997. https://datatracker.ietf.org/doc/html/rfc2182
3. Cloudflare Learning Center, "DNS NS record," https://www.cloudflare.com/learning/dns/dns-records/dns-ns-record/