Dns Records - Learning Module

Loading content...

0/228

NS Records: The Foundation of DNS Delegation

Delegation: The Architecture of Distributed DNS

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.

What You Will Master

By the end of this page, you will understand: (1) The precise semantics and wire format of NS records, (2) How NS records enable zone delegation, (3) The critical role of glue records in avoiding circular dependencies, (4) Authoritative vs. referral NS records, (5) NS record maintenance and best practices, and (6) Security considerations including NS record hijacking and DNSSEC implications.

NS Record Fundamentals

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:

Field	Size	Description
NAME	Variable	The delegated domain
TYPE	2 bytes	Record type = 2 (NS)
CLASS	2 bytes	Class = 1 (IN = Internet)
TTL	4 bytes	Time-to-live in seconds
RDLENGTH	2 bytes	Length of RDATA
RDATA	Variable	Nameserver hostname (may use compression)

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.

NS Records Point to Hostnames, Not IPs

Like MX records, NS records point to hostnames rather than IP addresses. This allows the nameserver's address to change without updating delegation records in parent zones. However, this indirection creates special challenges when the nameserver hostname is within the zone being delegated—requiring "glue records" (covered in Section 3).

Zone Delegation Mechanics

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

Converting Mermaid diagram...

Resolution Through Delegation

When resolving api.subdomain.example.com:

Root servers → Return NS records for .com TLD
.com TLD → Return NS records for example.com
example.com NS → Return delegation NS records for subdomain.example.com
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: Breaking Circular Dependencies

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:

Query .com TLD for www.example.com
TLD says: "Ask ns1.example.com"
To ask ns1.example.com, we need its IP address
To get the IP of ns1.example.com, we need to query... the example.com zone
But to query the example.com zone, we need ns1.example.com's IP
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:

NS Hostname	Zone Delegated	Glue Required?
ns1.example.com	example.com	Yes — ns1 is within zone
ns.hostingco.net	example.com	No — ns is in different zone
ns1.sub.example.com	sub.example.com	Yes — ns1 is within zone
ns1.example.com	sub.example.com	No — ns1 is in parent zone

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

Stale Glue Attacks

If an attacker gains control of the IP addresses specified in glue records (e.g., after you change providers but forget to update registrar glue), they can hijack your zone. Always update glue records at the registrar simultaneously with changes to your authoritative servers' IP addresses.

NS Record Placement and TTL Strategy

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.

NS Record TTL Guidelines
Scenario	Recommended TTL	Rationale
Stable infrastructure	86400 (24 hours)	Maximize caching, reduce queries to parent zone
Planned migration	3600 → 300	Lower TTL days before change, restore after
Root/TLD zones	172800 (48 hours)	Maximum stability for critical infrastructure
Dynamic environments	3600 (1 hour)	Balance between caching and flexibility
Testing	300 (5 minutes)	Rapid iteration, restore to production TTL before launch

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:

First query for www.example.com → Full resolution, NS records cached
Second query for mail.example.com → Use cached NS records, skip parent zone
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.

Checking NS Consistency

Use dig to compare parent and child NS records:

dig NS example.com @a.gtld-servers.net (parent/TLD) dig NS example.com @ns1.example.com (child)

Both should return identical NS records. Discrepancies indicate misconfiguration.

NS Record Operations: Adding, Changing, and Removing

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)

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

Test resolution from new nameservers:

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

Phase 2: Update Parent Zone

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

Phase 3: Verification

Verify from multiple global locations:

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

Check DNSSEC chain if signed
Monitor for resolution failures

Phase 4: Cleanup

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

Safe NS Change Practices

•Pre-deploy zone to new servers before updating delegation
•Lower TTL in advance to reduce stale cache duration
•Maintain old servers until all caches expire
•Test from multiple locations including different ISPs
•Update DNSSEC DS records if changing to new KSK
•Document the change with timestamps

Common NS Change Mistakes

•Turning off old servers immediately — breaks cached NS
•Forgetting glue record updates — breaks resolution
•Not pre-deploying zone — new NS returns REFUSED
•Ignoring DNSSEC chain — validation failures
•Changing during high traffic — maximize impact
•Not testing beforehand — discovering issues in production

Adding Nameservers

When adding capacity or redundancy:

Deploy zone to new nameserver

Add NS record in zone file:

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

Add NS record at registrar (if in-bailiwick, add glue too)
Verify resolution includes new server:
```
dig NS example.com +short | sort
```

Removing Nameservers

Important: Never reduce below two nameservers.

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

Nameserver Hostname Changes

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

Add the new hostname as an additional NS
Wait for propagation
Remove the old hostname
Wait for caches to expire
Optionally rename the actual server

NS Records and DNSSEC

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:

DS record — Hash of child's DNSKEY, establishing trust
NS records — Unsigned referral to child nameservers
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:

If keeping same keys: Standard NS migration procedure applies
If changing KSK: Must coordinate DS record update with parent zone
If disabling DNSSEC: Remove DS record before changing NS
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:

Pre-publish new DNSKEY in old zone (if possible)
Or: Submit new DS to parent zone
Wait for DS propagation (can take hours to days)
Update NS records
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."

DNSSEC Breaks If DS Mismatches

If the DS record in the parent zone doesn't match any DNSKEY in the child zone, DNSSEC validation fails and the entire zone becomes unreachable to validating resolvers. This is a common cause of DNSSEC outages. Always verify DS/DNSKEY alignment after any nameserver or key change.

Security Considerations

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).

NS Security Best Practices

•Enable registry lock for high-value domains (requires human verification for changes)
•Use strong authentication (MFA) on all registrar accounts
•Enable DNSSEC to cryptographically bind zone data to keys
•Monitor for unauthorized NS changes via DNS monitoring services
•Use nameserver hostnames you control — avoid dependency on third-party domains
•Maintain valid contact information at registrar for recovery
•Distribute nameservers geographically across providers
•Keep registrar credentials separate from general IT credentials

Registry Lock Explained

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

Changes to NS records require out-of-band verification
Usually involves phone call to registry/registrar with security questions
Adds 24-48 hour delay to any changes
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

Summary and Key Takeaways

We've conducted a comprehensive exploration of NS records—the DNS mechanism enabling zone delegation and the distributed DNS hierarchy. Let's consolidate the essential knowledge:

Master-Level Understanding Achieved

•NS records identify authoritative nameservers for a zone, enabling the hierarchical delegation structure of DNS
•Glue records break circular dependencies when nameserver hostnames are within the zone being delegated
•NS records appear in both parent and child zones — parent for delegation/referral, child for authoritative apex data
•TTL strategy matters — longer TTLs reduce load but slow migration; lower before changes, restore after
•DNSSEC creates special considerations — DS records establish trust chain, must be coordinated with NS changes
•Security is paramount — NS record compromise means total zone control; use registry lock, monitoring, and strong authentication

Page Complete

You now possess Principal Engineer-level understanding of NS records—from wire format to delegation mechanics, glue records to DNSSEC interaction, and security considerations. In the next page, we'll explore TXT records and other specialized record types that extend DNS beyond address resolution to serve authentication, verification, and policy functions.