DNS NS Record Explained — Nameserver Delegation

NS (Name Server) records are the mechanism that makes the entire Domain Name System work. Every DNS lookup ultimately depends on NS records to find the authoritative servers that hold the answer. Without NS records, there would be no way to navigate the DNS hierarchy from root servers down to the nameserver that knows the A record or AAAA record for a given domain.

An NS record specifies the hostname of a DNS server that is authoritative for a particular zone:

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

These records tell every DNS resolver on the internet: "If you need information about example.com, ask ns1.dnscale.eu or ns2.dnscale.eu."

How Delegation Works in the DNS Hierarchy

DNS is organized as an inverted tree. At the top are the root servers, below them are the TLD (Top-Level Domain) servers, and below those are the authoritative servers for individual domains. NS records are the pointers that connect each level to the next.

When a recursive resolver needs to look up www.example.com, it follows the delegation chain:

1. Root servers — The resolver asks a root server for www.example.com. The root server does not know the answer, but it returns the NS records for the .com TLD: a.gtld-servers.net, b.gtld-servers.net, etc.
2. TLD servers — The resolver asks a .com TLD server. It does not know the final answer either, but it returns the NS records for example.com: ns1.dnscale.eu, ns2.dnscale.eu.
3. Authoritative servers — The resolver asks ns1.dnscale.eu for www.example.com and gets the definitive answer.

Each step in this chain is a delegation — a parent zone pointing to the child zone's nameservers via NS records. This is what makes DNS a distributed, scalable system rather than a single centralized database.

Tip: You can watch this entire delegation chain happen in real time using dig +trace. See the tracing delegation with dig section below.

Zone Apex NS Records vs Subdomain Delegation

Zone Apex NS Records

Every DNS zone must have at least two NS records at its apex (the root of the zone). These records declare which nameservers are authoritative for the entire zone:

example.com.    86400    NS    ns1.dnscale.eu.
example.com.    86400    NS    ns2.dnscale.eu.

Apex NS records exist in two places simultaneously:

• At the parent zone (the TLD) — These are the delegation records that the .com servers return when asked about example.com. You set these at your domain registrar.
• At the zone itself — These are the authoritative NS records within your zone file. You set these at your DNS provider (DNScale).

Both sets must match. If they diverge, DNS resolution may become unreliable because resolvers get conflicting information about where to find authoritative answers.

Subdomain Delegation

NS records are not limited to the zone apex. You can place NS records at any subdomain to delegate that subdomain to a different set of nameservers:

; Main zone on DNScale
example.com.         86400    NS    ns1.dnscale.eu.
example.com.         86400    NS    ns2.dnscale.eu.
 
; dev subdomain delegated to a team's own nameservers
dev.example.com.     3600     NS    ns1.devteam.internal.
dev.example.com.     3600     NS    ns2.devteam.internal.
 
; aws subdomain delegated to Route 53
aws.example.com.     3600     NS    ns-123.awsdns-12.com.
aws.example.com.     3600     NS    ns-456.awsdns-34.net.

With subdomain delegation, the parent zone only needs the NS records for the delegated subdomain. All record types within that subdomain — A, AAAA, MX, TXT, CAA, and others — are managed entirely on the delegated nameservers.

This is commonly used for:

• Delegating cloud infrastructure subdomains to providers like AWS Route 53 or Google Cloud DNS
• Giving development teams autonomous control over their subdomain
• Running split-horizon DNS where internal and external views are served by different nameservers
• Implementing a multi-provider DNS deployment at the subdomain level

Glue Records and Why They Exist

A glue record is an A or AAAA record provided by the parent zone for a nameserver whose hostname is within the zone it serves. Glue records break what would otherwise be a circular dependency.

Consider this scenario:

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

To look up anything in example.com, a resolver needs to contact ns1.example.com. But to find the IP address of ns1.example.com, the resolver needs to query the example.com zone — which it cannot reach without first knowing the IP of ns1.example.com. This is a chicken-and-egg problem.

Glue records solve this. The parent zone (the .com TLD in this case) stores the IP addresses of the in-zone nameservers alongside the NS delegation:

; At the .com TLD (delegation + glue)
example.com.        86400    NS    ns1.example.com.
example.com.        86400    NS    ns2.example.com.
ns1.example.com.    86400    A     198.51.100.1
ns2.example.com.    86400    A     198.51.100.2

When the resolver gets the NS referral from .com, it also receives the glue A records in the additional section of the DNS response. This gives it the IP addresses it needs to contact the nameservers directly.

Tip: If your nameservers are outside your own domain (e.g., ns1.dnscale.eu for example.com), no glue records are needed. The resolver can independently look up ns1.dnscale.eu through the .eu TLD without any circular dependency. Glue records are only necessary for in-zone nameservers.

Tracing Delegation with dig +trace

The dig +trace command shows the complete delegation path from the root servers to the authoritative answer. This is invaluable for debugging NS delegation issues:

dig +trace www.example.com

Example output (abbreviated):

; <<>> DiG 9.18.18 <<>> +trace www.example.com
.                   518400  IN  NS  a.root-servers.net.
.                   518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 198.41.0.4#53(a.root-servers.net)
 
com.                172800  IN  NS  a.gtld-servers.net.
com.                172800  IN  NS  b.gtld-servers.net.
;; Received 772 bytes from 199.7.83.42#53(l.root-servers.net)
 
example.com.        172800  IN  NS  ns1.dnscale.eu.
example.com.        172800  IN  NS  ns2.dnscale.eu.
;; Received 114 bytes from 192.26.92.30#53(c.gtld-servers.net)
 
www.example.com.    3600    IN  A   198.51.100.10
;; Received 62 bytes from 185.x.x.1#53(ns1.dnscale.eu)

Each section shows a delegation step: root to .com, .com to example.com's nameservers, and finally the authoritative answer from DNScale.

Verifying Subdomain Delegation

# Trace a delegated subdomain
dig +trace api.dev.example.com
 
# Check NS records for a specific subdomain
dig NS dev.example.com
 
# Query the parent zone's nameserver to see the delegation
dig NS dev.example.com @ns1.dnscale.eu

Checking Glue Records

# Query the TLD server directly to see glue records
dig NS example.com @a.gtld-servers.net +additional

The additional section of the response will contain the glue A/AAAA records if your nameservers are in-zone.

How to Change Nameservers

Changing nameservers involves two distinct steps that are often confused:

Step 1: Update at the Registrar

The registrar controls the NS delegation at the TLD level. When you change nameservers at your registrar, you are updating the records that .com (or your TLD) returns when asked about your domain.

This is a separate system from your DNS zone file. The registrar communicates with the TLD registry (e.g., Verisign for .com) to update the delegation.

Step 2: Update in the Zone

Your DNS zone's apex NS records should match what the registrar has set. When migrating to DNScale, the zone is created with DNScale's NS records automatically:

example.com.    86400    NS    ns1.dnscale.eu.
example.com.    86400    NS    ns2.dnscale.eu.

Tip: Always set up the new DNS provider and verify your records are correct before changing the nameservers at your registrar. This avoids downtime during the transition. Read more about registrar vs DNS hosting to understand the distinction.

TTL Considerations for NS Records

NS records typically use long TTLs because nameserver assignments change rarely:

Changing NS records is one of the slowest DNS propagation events because TLD servers cache NS records with long TTLs that you do not control. Plan nameserver migrations carefully and lower your TTL well in advance.

Redundancy — Minimum Two NS Records

The DNS specification requires at least two authoritative nameservers for every zone. This is not just a formality — it is a critical redundancy requirement:

• If one nameserver is unreachable (hardware failure, network issue, DDoS attack), the other continues to serve queries
• Nameservers should be on different networks and ideally in different geographic locations
• Having nameservers on the same physical server or network provides no real redundancy

DNScale provides multiple nameservers across its anycast network, meaning each NS hostname actually resolves to a fleet of servers distributed across multiple points of presence. This provides far greater redundancy than two individual servers.

Vanity Nameservers

Some organizations prefer to display their own branded nameserver names instead of their DNS provider's names:

; Instead of:
example.com.    86400    NS    ns1.dnscale.eu.
 
; Use vanity nameservers:
example.com.    86400    NS    ns1.example.com.
example.com.    86400    NS    ns2.example.com.

Vanity nameservers require:

1. NS records pointing to hostnames in your own domain
2. Glue records at the registrar providing the IP addresses of those hostnames (since they are in-zone)
3. The underlying DNS service still runs on your provider's infrastructure — the vanity names are CNAMEs or direct IP mappings to the provider's servers

Tip: Vanity nameservers add operational complexity. If your provider changes their IP addresses, you need to update glue records at the registrar. Unless branding is important, using the provider's default nameserver names is simpler and more reliable.

NS Records for Split-Horizon DNS

Split-horizon DNS serves different answers depending on where the query comes from (internal network vs public internet). NS records enable this through subdomain delegation:

; Public zone on DNScale
example.com.              86400    NS    ns1.dnscale.eu.
example.com.              86400    NS    ns2.dnscale.eu.
 
; Internal subdomain delegated to corporate DNS
internal.example.com.     3600     NS    dns1.corp.example.com.
internal.example.com.     3600     NS    dns2.corp.example.com.

Internal clients resolve app.internal.example.com through the corporate DNS servers, which return private IP addresses. External clients cannot reach the internal nameservers and thus cannot resolve internal hostnames. This is a clean separation that does not require complex DNS views.

Common Mistakes

Circular Delegation

Circular delegation occurs when zone A delegates to a nameserver in zone B, and zone B delegates to a nameserver in zone A, without proper glue records:

; Zone A delegates to a server in Zone B
a.example.    86400    NS    ns.b.example.
 
; Zone B delegates to a server in Zone A
b.example.    86400    NS    ns.a.example.

Without glue records at the parent level, neither zone can be resolved. Always ensure that at least one nameserver in each delegation chain can be resolved independently.

Missing Glue Records

If your nameservers are within your own domain and you forget to add glue records at the registrar, your entire domain becomes unresolvable. This is one of the most common causes of complete DNS outages after a nameserver change.

Mismatched NS Records

When the NS records at the registrar (parent zone) do not match the NS records in your zone file, resolvers can get inconsistent delegation information. Some DNSSEC validators may also flag this as a configuration error.

# Check parent delegation
dig NS example.com @a.gtld-servers.net
 
# Check authoritative zone
dig NS example.com @ns1.dnscale.eu
 
# Both should return the same nameserver set

Using IP Addresses Instead of Hostnames

NS records must contain hostnames, not IP addresses. This is a common misconception:

; WRONG
example.com.    86400    NS    198.51.100.1
 
; CORRECT
example.com.    86400    NS    ns1.dnscale.eu.

Pointing NS Records to CNAMEs

The target of an NS record must resolve directly to an A or AAAA record. NS records must never point to a CNAME. This is explicitly prohibited by RFC 2181 and will cause resolution failures with many resolvers.

How DNScale Anycast Nameservers Work

DNScale operates two sets of anycast nameservers across two autonomous systems:

• EU nameservers — Announced from European points of presence for zones requiring EU-only DNS resolution
• Global nameservers — Announced from POPs across Europe, North America, and additional regions for worldwide coverage

When you create a zone in DNScale, it is automatically assigned the appropriate nameserver set. Each nameserver hostname (e.g., ns1.dnscale.eu) resolves to an anycast IP address that is announced via BGP from multiple locations simultaneously.

This means a dig query to ns1.dnscale.eu from Amsterdam is answered by the Amsterdam POP, while the same query from Chicago is answered by the Chicago POP. The resolver always reaches the nearest healthy server, providing low latency and automatic failover if a POP goes offline.

For details on how BGP anycast routing works, read the Anycast DNS Network guide. For information on how DNScale balances queries across its network, see Global DNS Resolution Balancing.

Related Record Types

• A records — Required as glue records for in-zone nameservers
• AAAA records — IPv6 glue records for nameservers
• SOA record — Start of Authority, always accompanies NS records at the zone apex
• CNAME records — Cannot be used as NS targets (a common mistake)
• All DNS record types — Complete overview of every DNS record type

Conclusion

NS records are the backbone of DNS delegation. They connect every level of the DNS hierarchy, from root servers down to individual zones and their subdomains. Understanding how NS records, glue records, and the delegation chain work together is essential for managing DNS reliably. Whether you are pointing your domain to DNScale's anycast nameservers, delegating subdomains to other providers, or debugging resolution failures with dig +trace, NS records are at the center of it all. DNScale handles apex NS records automatically and makes subdomain delegation straightforward through its dashboard and API.