← DNS RecordsRecord Type / Delegation

NS Record

Identifies the authoritative nameservers for a domain. These records define the delegation chain that makes the distributed DNS system work.

Overview

Nameserver Delegation

NS records specify which nameservers are authoritative for a zone. There are two places NS records exist: in the parent zone (the TLD nameservers hold NS records for every domain they delegate) and in the zone itself (the authoritative nameservers hold their own NS records).

When you register a domain and configure nameservers at your registrar, the registrar notifies the TLD registry to publish NS records pointing to your nameservers in the parent zone. These are the delegation NS records. Your zone should publish matching NS records — a mismatch between parent and child NS records is called a lame delegation.

  • At minimum two NS records are required for redundancy (RFC 1035 recommendation)
  • NS records must point to hostnames, not IP addresses or CNAMEs
  • Parent zone NS records and your zone's own NS records should match exactly
  • Glue records are required when NS records point to subdomains of the zone being delegated
  • NS TTL is typically 86400s (24h) — these change rarely and long caching reduces root/TLD load
  • Changing NS records requires updating both your registrar AND your zone file
; Syntax ; Name [TTL] IN NS nameserver-hostname. ; Zone apex NS records (in your zone file) @ 86400 IN NS ns1.cloudflare.com. @ 86400 IN NS ns2.cloudflare.com. ; Parent zone delegation (held by TLD) ; (what .guru TLD nameservers hold for thedns.guru) thedns.guru. IN NS ns1.cloudflare.com. thedns.guru. IN NS ns2.cloudflare.com. ; Subdomain delegation (sub-zone) sub.example.com. IN NS ns1.sub.example.com. sub.example.com. IN NS ns2.sub.example.com. ; ↑ requires glue records (see below)
Lame DelegationA lame delegation occurs when the NS records in the parent zone don't match the actual nameservers for the domain, or when the listed nameserver doesn't answer authoritatively for the zone. Lame delegations cause resolution failures or timeouts and are a common source of DNS takeover vulnerabilities.
Glue Records

When NS Records Need Glue

A glue record is an A or AAAA record provided in the additional section of a DNS referral response, when the nameserver hostname is within the zone being delegated. Without glue, there would be a circular dependency: to find example.com, you need to ask ns1.example.com — but to find ns1.example.com, you need example.com to be resolved first.

Glue records are registered at the parent registry when you use in-bailiwick nameservers (nameservers within your own domain). They are stored by the TLD registry and returned automatically during the referral step of DNS resolution.

; Circular dependency problem: ; NS records point into the zone itself example.com. NS ns1.example.com. example.com. NS ns2.example.com. ; ↑ To resolve this, I need ; example.com... but I'm ; trying to resolve it! ; Solution: glue records in the parent zone ; (stored at .com TLD nameservers) example.com. NS ns1.example.com. example.com. NS ns2.example.com. ns1.example.com. A 203.0.113.1 ; ← glue ns2.example.com. A 203.0.113.2 ; ← glue ; Out-of-bailiwick = no glue needed ; (NS points to a different domain) example.com. NS ns1.cloudflare.com. ; cloudflare.com resolves independently
Diagnostics

Querying NS Records

Check zone NS records

# Query NS records from your zone dig thedns.guru NS +short # Query NS from parent TLD # (to verify delegation matches) TLD_NS=$(dig guru NS +short | head -1) dig thedns.guru NS @$TLD_NS +short # Both should return the same servers

Detect lame delegations

# Test if each NS is authoritative for NS in $(dig thedns.guru NS +short); do echo -n "$NS: " dig thedns.guru SOA @$NS +short \ && echo "OK" || echo "LAME" done

Check for glue records

# Query with +additional to see glue TLD_NS=$(dig guru NS +short | head -1) dig thedns.guru NS @$TLD_NS +additional # Look for A records in ADDITIONAL # section — those are glue records

Verify NS consistency

# Query each NS server for SOA # serial — should match for NS in $(dig thedns.guru NS +short); do echo -n "$NS serial: " dig thedns.guru SOA @$NS +short \ | awk '{print $3}' done # Mismatched serials = replication lag