What Is an NS Record

An NS (Name Server) record specifies which DNS servers are authoritative for a domain or subdomain. NS records are fundamental to how DNS delegation works, enabling the hierarchical structure of the Domain Name System. Every domain on the internet relies on NS records to tell resolvers where to find the answers for that domain.

How NS Records Work

NS records tell DNS resolvers which servers can answer queries for a domain:

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

When a resolver needs information about example.com, it follows the delegation chain: root servers point to the .com TLD servers, which return the NS records for example.com, which in turn point the resolver to ns1.dnscale.eu and ns2.dnscale.eu. These authoritative servers then provide the actual A records, AAAA records, MX records, and all other record types for the zone.

The Delegation Chain

Understanding where NS records fit in the DNS hierarchy is critical:

1. Root zone contains NS records for TLD servers (.com, .net, .eu, etc.)
2. TLD zone contains NS records for each registered domain (e.g., example.com)
3. Domain zone contains NS records for itself (apex) and optionally for delegated subdomains

When you register a domain and set the nameservers at your registrar, you are updating the NS records in the TLD zone. When you create subdomain delegations in DNScale, you are adding NS records in your own zone.

You can observe this entire chain with dig +trace:

dig +trace example.com

This command walks the DNS hierarchy from root to authoritative, showing each NS referral along the way.

Types of NS Records

Zone Apex NS Records

Every DNS zone must have NS records at the apex (root) pointing to its authoritative nameservers:

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

These apex NS records are system records in DNScale and are protected from accidental modification, since changing them incorrectly would break resolution for your entire domain.

Subdomain Delegation

Delegate a subdomain to different nameservers:

; Main zone uses DNScale
example.com.         86400    NS    ns1.dnscale.eu.
example.com.         86400    NS    ns2.dnscale.eu.
 
; Subdomain delegated to different nameservers
dev.example.com.     86400    NS    ns1.devteam.example.
dev.example.com.     86400    NS    ns2.devteam.example.

When a resolver queries for anything under dev.example.com, the DNScale nameservers return the NS referral, and the resolver follows it to ns1.devteam.example and ns2.devteam.example. This is how large organizations split DNS management across teams or providers.

Common Use Cases

Standard Zone Configuration

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

Subdomain Delegation to Different Provider

Delegate a subdomain to AWS Route 53 while keeping the main zone on DNScale:

aws.example.com.    3600    NS    ns-123.awsdns-12.com.
aws.example.com.    3600    NS    ns-456.awsdns-34.net.
aws.example.com.    3600    NS    ns-789.awsdns-56.org.
aws.example.com.    3600    NS    ns-012.awsdns-78.co.uk.

This is commonly used in multi-provider DNS deployments and regional DNS delegation.

Internal Subdomain Delegation

Delegate internal domains to corporate nameservers:

internal.example.com.    3600    NS    dns1.corp.example.com.
internal.example.com.    3600    NS    dns2.corp.example.com.

When delegating to nameservers within your own domain (e.g., dns1.corp.example.com), you must also add glue records. See the Glue Records section below.

Record Format

Glue Records

When a nameserver's hostname is within the zone it serves, you need glue records -- A or AAAA records for the nameserver that are included alongside the NS delegation:

example.com.        86400    NS      ns1.example.com.
example.com.        86400    NS      ns2.example.com.
ns1.example.com.    86400    A       192.0.2.1
ns2.example.com.    86400    A       192.0.2.2

Without glue records, DNS resolution would create a circular dependency: to resolve example.com, you need to reach ns1.example.com, but to find the IP of ns1.example.com, you need to resolve example.com. Glue records break this cycle by providing the IP addresses directly in the referral response.

When Glue Records Are Required

Glue records are configured at the domain registrar level, not in the zone file. Your registrar provides a way to add "host records" or "nameserver IPs" for this purpose.

Vanity Nameservers

Some organizations prefer nameservers that match their domain (e.g., ns1.example.com instead of ns1.dnscale.eu). These are called vanity nameservers or white-label nameservers. They require:

1. NS records pointing to your vanity hostnames
2. Glue records (A/AAAA) at the registrar for those hostnames
3. The actual nameserver software configured to respond for your domain

Vanity nameservers add branding but also add operational complexity. With DNScale, our nameservers (ns1.dnscale.eu, ns2.dnscale.eu) are served from a global anycast network, providing speed and redundancy.

Querying NS Records with dig

# Query NS records for a domain
dig NS example.com
 
# Get just the nameserver hostnames
dig NS example.com +short
 
# Check authoritative response
dig NS example.com @ns1.dnscale.eu
 
# Verify subdomain delegation
dig NS subdomain.example.com
 
# Full trace showing the entire delegation chain
dig +trace example.com
 
# Verify glue records are present
dig NS example.com @a.gtld-servers.net

The +trace option is particularly valuable for NS debugging. It shows each step of the resolution process, making it easy to spot where delegation breaks:

dig +trace www.dev.example.com

This would show: root servers -> .com TLD -> example.com NS -> dev.example.com NS -> final answer.

If dig +trace stops returning answers at a certain level, the delegation at that level is likely broken. Check that the NS records at the parent zone match the actual nameserver configuration.

Adding an NS Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter subdomain name or @ for apex
   • Type: Select NS
   • Value: Enter the nameserver hostname
   • TTL: Set the cache duration (default: 86400 for NS)
4. Click Create Record

Using the API

Create an NS record for subdomain delegation:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "subdomain",
    "type": "NS",
    "content": "ns1.other-provider.com",
    "ttl": 86400
  }'

Delegate a subdomain to multiple nameservers:

# First nameserver
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "aws",
    "type": "NS",
    "content": "ns-123.awsdns-12.com",
    "ttl": 3600
  }'
 
# Second nameserver
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "aws",
    "type": "NS",
    "content": "ns-456.awsdns-34.net",
    "ttl": 3600
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "subdomain.example.com.",
      "type": "NS",
      "content": "ns1.other-provider.com.",
      "ttl": 86400,
      "disabled": false
    }
  }
}

Troubleshooting NS Records

Domain not resolving? Check these common NS issues:

1. Registrar and zone mismatch: The NS records at your registrar must match the NS records in your zone. Run dig NS example.com @a.gtld-servers.net (TLD level) and compare with dig NS example.com @ns1.dnscale.eu (zone level).
2. Missing glue records: If using in-zone nameservers, verify glue records exist at the registrar.
3. Nameserver not responding: The nameserver listed in the NS record must actually be running and configured to serve your zone. Test with dig @ns1.dnscale.eu example.com.
4. Propagation delay: NS record changes can take up to 48 hours to propagate through all caches due to the typically long TTLs. See DNS Propagation Explained.
5. DNSSEC issues: If DNSSEC is enabled, NS changes require careful handling of DS records at the parent zone.

Best Practices

1. Always have multiple NS records - At least 2 nameservers for redundancy, ideally on different networks. DNScale provides ns1.dnscale.eu and ns2.dnscale.eu with anycast for geographic diversity.

2. Use long TTLs - NS records should have long TTLs (86400 seconds = 24 hours) since they change rarely. See DNS TTL Best Practices.

3. NS targets must not be CNAMEs - Nameservers must resolve directly via A/AAAA records, never through CNAME records.

4. Keep parent and child zones in sync - NS records at the registrar must match your zone's NS records.

5. Geographic diversity - Use nameservers in different locations for resilience. Consider multi-provider DNS for maximum availability.

6. Don't modify apex NS without care - Changing apex NS records incorrectly can break your entire domain. These are system records in DNScale.

NS Records vs Registrar Nameservers

Both must match for proper DNS resolution. Changing nameservers at the registrar without updating the zone (or vice versa) will cause resolution failures.

Related Record Types

• A - IP address for glue records
• AAAA - IPv6 address for glue records
• SOA - Start of Authority (zone metadata)
• System Records - Why apex NS records are protected from modification
• PTR - Reverse DNS delegation
• CNAME - Cannot be used as NS target

Conclusion

NS records are the backbone of DNS delegation, determining which servers are authoritative for your domains and subdomains. From the root zone down to individual subdomain delegations, NS records create the hierarchical structure that makes DNS scalable and distributed. Understanding glue records, the relationship between registrar and zone NS records, and how to use dig +trace for debugging will help you confidently manage even complex multi-provider setups. While apex NS records are typically managed automatically by DNScale as system records, subdomain delegation gives you the flexibility to split DNS authority across teams and providers.