NS record

What is an NS record?

An NS record (Nameserver record) is a DNS record type that specifies which DNS servers are authoritative for a particular domain. NS records delegate DNS resolution authority, telling the global DNS system where to find the official DNS information for a domain or subdomain. Every registered domain must have at least two NS records pointing to its authoritative nameservers for redundancy and reliability.

How NS records work

DNS delegation chain

Root servers (.): "Who handles .com?"
    ↓
.com servers: "example.com is delegated to ns1.example.com"
    ↓
ns1.example.com: "Here are the actual DNS records"

Record format

example.com.    IN    NS    ns1.example.com.
example.com.    IN    NS    ns2.example.com.
        │       │     │          │
        │       │     │          └── Target nameserver
        │       │     └── Record type
        │       └── Class (Internet)
        └── Domain name

Types of NS records

Domain NS records

Delegate authority for an entire domain:

example.com.    NS    ns1.dnsprovider.com.
example.com.    NS    ns2.dnsprovider.com.

Subdomain delegation

Delegate a subdomain to different nameservers:

subdomain.example.com.    NS    ns1.subdomain-provider.com.
subdomain.example.com.    NS    ns2.subdomain-provider.com.

Glue records

When nameservers are within the delegated domain, glue records provide IP addresses to prevent circular dependencies:

The problem

example.com NS ns1.example.com
# How to find ns1.example.com without resolving example.com first?

The solution (glue records)

example.com.        NS    ns1.example.com.
ns1.example.com.    A     192.0.2.1

Glue records are stored at the parent zone (registry level) to bootstrap resolution.

NS record configuration

At registry level

When you register a domain, you specify nameservers:

• These become the authoritative NS records
• Stored in the TLD zone (e.g., .com zone)
• Managed through registrar control panel

At DNS provider level

Within your zone file:

@    IN    NS    ns1.example.com.
@    IN    NS    ns2.example.com.

Best practices

Redundancy requirements

Geographic distribution

• Place nameservers in different data centers
• Use different network providers
• Consider Anycast DNS for global coverage

TTL considerations

example.com.  86400  IN  NS  ns1.example.com.
              ↑ 24 hours is common for NS records

• Higher TTLs reduce query load
• Lower TTLs enable faster changes
• Balance stability vs flexibility

Common NS record scenarios

Using registrar's nameservers

example.com.    NS    ns1.registrar.com.
example.com.    NS    ns2.registrar.com.

Using third-party DNS provider

example.com.    NS    ns1.cloudflare.com.
example.com.    NS    ns2.cloudflare.com.

Self-hosted nameservers

example.com.    NS    ns1.example.com.
example.com.    NS    ns2.example.com.
# Requires glue records

Checking NS records

Using dig

dig example.com NS

# Response shows authoritative nameservers
;; ANSWER SECTION:
example.com.    86400    IN    NS    ns1.example.com.
example.com.    86400    IN    NS    ns2.example.com.

Using nslookup

nslookup -type=NS example.com

Troubleshooting NS issues

Common problems and solutions:

• Lame delegation: NS record points to non-authoritative server
• Missing glue: Self-referential nameservers without A records at registry
• Inconsistent NS: Different NS records at registry vs zone file
• Expired nameservers: NS pointing to decommissioned servers

NS records form the foundation of DNS delegation, determining which servers have authority to answer queries for any given domain or subdomain.