NS Records: The Foundation of DNS Delegation

The Domain Name System's power lies not in any single server but in its distributed, hierarchical architecture. At the heart of this architecture is a simple but profound concept: delegation. NS records (Name Server records) are the mechanism by which one zone delegates authority over a subdomain to another set of nameservers.

When you type www.example.com in a browser, the resolution process traverses the DNS hierarchy: root servers delegate to .com TLD servers, which delegate to example.com's authoritative nameservers. Each step in this hierarchy is defined by NS records. Without NS records, DNS would require a single, centralized database—an impossible architecture at Internet scale.

This page provides exhaustive coverage of NS records: their role in zone delegation, their relationship with glue records, their interaction with DNSSEC, and their critical importance in both routine operations and infrastructure security.

The NS record (Name Server record) is defined in RFC 1035 as part of the original DNS specification. Its purpose is to identify the authoritative nameservers for a zone.

Formal Definition

An NS record establishes a relationship between:

• Domain Name: The zone being delegated
• Nameserver Hostname: The hostname of a server authoritative for that zone

The abstract representation:

<domain>  IN  NS  <nameserver-hostname>

For example:

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

These records declare: "Authoritative answers for example.com and its subdomains can be obtained from ns1.example.com and ns2.example.com."

Why Multiple NS Records?

RFC 2182 ("Selection and Operation of Secondary DNS Servers") recommends at least two authoritative nameservers for any zone, preferably with:

• Different network connectivity (diverse providers)
• Geographic distribution
• Different administrative domains

This redundancy ensures that a single server failure, network outage, or DDoS attack doesn't make the zone unresolvable.

NS Record Type Number: 2

In the DNS type hierarchy:

• Type 1 = A
• Type 2 = NS
• Type 5 = CNAME
• Type 6 = SOA

NS records have type number 2, reflecting their fundamental importance in DNS architecture.

NS Record Wire Format

In DNS messages, an NS record appears with the following structure:

The RDATA contains the nameserver's fully qualified domain name in standard DNS wire format.

Authoritative NS vs. Referral NS

NS records appear in two contexts:

1. Authoritative NS Records (at zone apex) These appear in the zone file of the zone itself:

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

2. Delegation/Referral NS Records (in parent zone) These appear in the parent zone, delegating to the child:

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

Both sets should match, though they're maintained separately.

Zone delegation is the fundamental mechanism that makes DNS scalable. Understanding how delegation works is essential for configuring DNS infrastructure correctly.

What Is a Zone?

A zone is a contiguous portion of the DNS namespace under a single administrative authority. A zone contains:

• All records for the domain and its subdomains
• Unless a subdomain is delegated to another zone

For example, example.com might be a zone containing:

• example.com (zone apex)
• www.example.com
• mail.example.com
• api.example.com

But if subdomain.example.com is delegated, it becomes a separate zone with its own authoritative servers.

The Delegation Process

To delegate subdomain.example.com from the example.com zone:

Step 1: In the parent zone (example.com)

Add NS records and glue (if needed):

; Delegation records in example.com zone file
subdomain.example.com.  86400  IN  NS  ns1.subdomain.example.com.
subdomain.example.com.  86400  IN  NS  ns2.otherdomain.com.

; Glue record (because ns1 is within the delegated zone)
ns1.subdomain.example.com.  86400  IN  A  192.0.2.1

Step 2: In the child zone (subdomain.example.com)

The child zone is configured on its own authoritative servers:

; Zone file for subdomain.example.com
$ORIGIN subdomain.example.com.
@  86400  IN  SOA  ns1.subdomain.example.com. admin.subdomain.example.com. ( ... )
@  86400  IN  NS   ns1.subdomain.example.com.
@  86400  IN  NS   ns2.otherdomain.com.

ns1  86400  IN  A   192.0.2.1
www  300    IN  A   192.0.2.10

Resolution Through Delegation

When resolving api.subdomain.example.com:

1. Root servers → Return NS records for .com TLD
2. .com TLD → Return NS records for example.com
3. example.com NS → Return delegation NS records for subdomain.example.com
4. subdomain.example.com NS → Return A record for api.subdomain.example.com

Each delegation adds a step, but enables independent management of each zone.

Authority Section in Referrals

When a nameserver doesn't have the answer but knows who does, it returns a referral in the authority section:

;; QUESTION SECTION:
api.subdomain.example.com.  IN  A

;; AUTHORITY SECTION:
subdomain.example.com.  86400  IN  NS  ns1.subdomain.example.com.
subdomain.example.com.  86400  IN  NS  ns2.otherdomain.com.

;; ADDITIONAL SECTION:
ns1.subdomain.example.com.  86400  IN  A  192.0.2.1

The authority section contains NS records for the closest enclosing zone. The additional section contains glue records for those nameservers.

Glue records are one of the most important yet frequently misunderstood concepts in DNS. They solve a fundamental circular dependency problem in zone delegation.

The Circular Dependency Problem

Consider this delegation:

; In the .com TLD zone
example.com.  NS  ns1.example.com.
example.com.  NS  ns2.example.com.

To resolve www.example.com:

1. Query .com TLD for www.example.com
2. TLD says: "Ask ns1.example.com"
3. To ask ns1.example.com, we need its IP address
4. To get the IP of ns1.example.com, we need to query... the example.com zone
5. But to query the example.com zone, we need ns1.example.com's IP
6. Infinite loop!

Glue Records as the Solution

Glue records provide the IP addresses of nameservers that are within the zone being delegated:

; 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   192.0.2.1
ns2.example.com.   172800  IN  A   192.0.2.2

The A records for ns1.example.com and ns2.example.com are glue records. They exist in the parent zone (.com) to break the circular dependency.

When Are Glue Records Required?

Glue is required when the nameserver hostname is within or below the zone being delegated:

Glue Record Best Practices

1. Keep Glue Synchronized

Glue records in the parent zone must match the actual A/AAAA records in the child zone. If they diverge, some resolvers may use stale glue while querying the child zone for updates.

2. Provide Both IPv4 and IPv6 Glue

ns1.example.com.   172800  IN  A     192.0.2.1
ns1.example.com.   172800  IN  AAAA  2001:db8::1

IPv6-only resolvers need AAAA glue to reach your nameservers.

3. Consider Out-of-Bailiwick Nameservers

Using nameservers outside your zone (e.g., ns1.hostingprovider.com) eliminates the need for glue management:

; No glue needed — nameservers are external
example.com.  NS  ns1.hostingprovider.com.
example.com.  NS  ns2.hostingprovider.com.

The resolver can resolve ns1.hostingprovider.com independently.

4. Registrar Glue Management

At the registrar level, glue records are called "host records" or "nameserver records." The registrar's interface allows you to:

• Create nameserver hostnames (e.g., ns1.yourdomain.com)
• Associate IP addresses with those hostnames
• Use those nameservers for your domain's delegation

Proper NS record configuration requires understanding both where NS records appear and how their TTL values affect DNS behavior.

NS Records Appear in Multiple Locations

1. Parent Zone (Delegation Point)

The parent zone contains delegation NS records. For example.com, the .com TLD zone contains:

; In .com TLD zone file (maintained by Verisign)
example.com.  172800  IN  NS  ns1.example.com.
example.com.  172800  IN  NS  ns2.example.com.

These records are managed by the parent zone operator (registrar submits changes).

2. Child Zone (Zone Apex)

The child zone contains authoritative NS records at its apex:

; In example.com zone file (you maintain this)
$ORIGIN example.com.
@  86400  IN  SOA  ns1.example.com. hostmaster.example.com. ( ... )
@  86400  IN  NS   ns1.example.com.
@  86400  IN  NS   ns2.example.com.

These records are managed by the zone administrator.

Parent vs. Child NS Records: Which Takes Precedence?

Technically, both are authoritative in their respective contexts:

• Parent NS records are authoritative as referral data
• Child NS records are authoritative as zone apex data

In practice, parent zone NS records are used for delegation (finding the zone), while child zone NS records are considered the authoritative source for the actual list of nameservers.

Consistency Between Parent and Child

While parent and child NS records should match, divergence can occur:

• When changing nameservers (parent updated but child not yet)
• Misconfigurations
• Intentional (rare) for specific routing purposes

Best Practice: Ensure parent and child NS records are identical. Divergence is a common source of DNS issues.

NS Records and Caching

NS records are cached by recursive resolvers. When a resolver handles many queries for names in a zone, the cached NS records eliminate repeated delegation lookups:

1. First query for www.example.com → Full resolution, NS records cached
2. Second query for mail.example.com → Use cached NS records, skip parent zone
3. Until NS TTL expires, all queries for *.example.com use cached NS

This is why NS TTLs are typically longer than content (A/AAAA) TTLs—the overhead of NS lookups is amortized across many queries.

Changing nameservers is a critical operation that, if done incorrectly, can make your domain unreachable. Here's how to perform NS changes safely.

Nameserver Change Procedure

Phase 1: Preparation (Days Before)

1. Lower NS record TTL in your current zone (e.g., from 86400 to 3600)
2. Wait for old TTL to expire (up to 24 hours)
3. Deploy zone to new nameservers and verify
4. Test resolution from new nameservers:

   dig @new-ns1.example.com www.example.com A
   

Phase 2: Update Parent Zone

1. Update NS records at registrar (this updates parent zone)
2. If using in-bailiwick nameservers, update glue records
3. Wait for parent zone to propagate (usually 1-48 hours)

Phase 3: Verification

1. Verify from multiple global locations:

   dig NS example.com @8.8.8.8
   dig NS example.com @1.1.1.1
   

2. Check DNSSEC chain if signed
3. Monitor for resolution failures

Phase 4: Cleanup

1. After 24-48 hours with no issues, restore normal TTL
2. Decommission old nameservers only after all caches expire

Adding Nameservers

When adding capacity or redundancy:

1. Deploy zone to new nameserver
2. Add NS record in zone file:

   @  86400  IN  NS  ns3.example.com.
   ns3  86400  IN  A  192.0.2.3
   

3. Add NS record at registrar (if in-bailiwick, add glue too)
4. Verify resolution includes new server:

   dig NS example.com +short | sort
   

Removing Nameservers

Important: Never reduce below two nameservers.

1. Remove NS record from zone file
2. Remove NS record at registrar (and glue if applicable)
3. Keep old server running for at least 2× the old TTL
4. Only then decommission the server

Nameserver Hostname Changes

If you need to rename a nameserver (not just add/remove):

1. Add the new hostname as an additional NS
2. Wait for propagation
3. Remove the old hostname
4. Wait for caches to expire
5. Optionally rename the actual server

DNSSEC adds cryptographic authentication to DNS, and NS records play a special role in the chain of trust.

NS Records Are Signed (In the Child Zone)

In a DNSSEC-signed zone, NS records at the zone apex are signed:

example.com.  86400  IN  NS     ns1.example.com.
example.com.  86400  IN  NS     ns2.example.com.
example.com.  86400  IN  RRSIG  NS 13 2 86400 ( ... signature ... )

The RRSIG proves the NS records weren't tampered with.

Delegation NS Records Are Not Signed by Parent

Here's a crucial subtlety: The parent zone doesn't sign the delegated NS records. Instead, it provides:

1. DS record — Hash of child's DNSKEY, establishing trust
2. NS records — Unsigned referral to child nameservers
3. NSEC/NSEC3 records — Prove no other records exist at delegation point

The unsigned NS records in referrals are safe because:

• The resolver follows them to query the child zone
• The child zone's signed NS records are authoritative
• DNSSEC validation occurs on the child's responses

The DS Record Connection

The DS (Delegation Signer) record in the parent zone is what enables DNSSEC validation:

; In .com TLD zone
example.com.  86400  IN  NS   ns1.example.com.
example.com.  86400  IN  NS   ns2.example.com.
example.com.  86400  IN  DS   12345 13 2 ( hashhashhashhash... )

The DS record contains:

• Key tag (12345) — Identifies which DNSKEY in child zone
• Algorithm (13) — ECDSA P-256
• Digest type (2) — SHA-256 hash
• Digest — Hash of the child's Key Signing Key (KSK)

NS and DNSSEC: Migration Considerations

When Changing Nameservers with DNSSEC:

1. If keeping same keys: Standard NS migration procedure applies
2. If changing KSK: Must coordinate DS record update with parent zone
3. If disabling DNSSEC: Remove DS record before changing NS
4. If enabling DNSSEC: Add DS record after new signed NS are live

DNSSEC Key Rollover with NS Changes:

If your new DNS provider uses different DNSSEC keys:

1. Pre-publish new DNSKEY in old zone (if possible)
2. Or: Submit new DS to parent zone
3. Wait for DS propagation (can take hours to days)
4. Update NS records
5. Ensure old DS covers old servers, new DS covers new servers

Unsigned Delegation (RFC 4035)

If a zone is not DNSSEC-signed, the parent zone contains:

• NS records (delegation)
• NSEC/NSEC3 records proving no DS exists

Validating resolvers see the absence of DS and don't expect the child to be signed. This is called an "unsigned delegation" or "insecure delegation."

NS records are high-value attack targets. Controlling a zone's NS records means controlling all resolution for that zone and its descendants.

Attack Vectors

1. Registrar Account Compromise The most common NS attack vector. Attackers gain access to registrar accounts and change nameserver delegation. High-profile incidents:

• The CryptoWallet.com hijack (2022)
• Malaysia Airlines (2015)
• LinkedIn (2012)

2. Registrar System Exploitation Exploiting vulnerabilities in registrar systems to modify NS records without authentication.

3. Expired Domain Nameserver Takeover If your NS points to a hostname in an expired domain, anyone who registers that domain controls your DNS:

; If hostingcompany.com expires...
example.com.  NS  ns1.hostingcompany.com.
; Attacker registers hostingcompany.com and takes over ns1

4. Glue Record Poisoning Attackers target registrar glue record management to inject malicious IP addresses.

5. Parent Zone Compromise Compromise of TLD operators or registries (rare but catastrophic).

Registry Lock Explained

Registry Lock (also called "registrar lock" or "transfer lock") adds an extra layer of protection:

1. Changes to NS records require out-of-band verification
2. Usually involves phone call to registry/registrar with security questions
3. Adds 24-48 hour delay to any changes
4. Prevents automated/compromised credential attacks

Available for most TLDs including .com, .net, .org. Cost varies by registrar.

Monitoring for NS Changes

Implement monitoring that alerts on NS record changes:

# Simple monitoring script
watch -n 3600 "dig NS example.com +short | sort | diff - expected_ns.txt"

Commercial services like DNS monitoring platforms provide:

• Global checks from multiple vantage points
• Historical NS record tracking
• Immediate alerts on changes
• DNSSEC validation monitoring