Updated 2 hours ago
Every domain resolution begins with ignorance.
When you query www.example.com, the root servers don't know the answer. The .com servers don't know either. Each one responds with the same message: "I don't know, but here's who does." This chain of referrals—made possible by NS records—is how DNS scales to billions of domains without any single server knowing everything.
What NS Records Do
NS (Name Server) records answer one question: "Who is authoritative for this domain?"
This tells resolvers: "For anything about example.com, ask ns1.nameserver.com or ns2.nameserver.com." Multiple NS records provide redundancy—if one name server fails, others can answer.
The Delegation Chain
DNS is a hierarchy, and NS records connect each level to the next. When you query www.example.com:
- Root servers don't know about example.com. Their NS records point to the
.comTLD servers. - TLD servers don't know about example.com either. Their NS records point to your domain's authoritative servers.
- Your authoritative servers finally have the answer—the A, AAAA, MX, or whatever record you're looking for.
Each server in the chain is doing something counterintuitive: proudly declaring its own ignorance. "I don't know about example.com, but here's who does." This deliberate not-knowing is what makes DNS work. No server needs omniscience. Each one only needs to know the next step.
NS Records Live in Two Places
This distinction prevents hours of debugging:
At Your Registrar
When you register a domain, your registrar stores NS records in the TLD registry. These are the records the Internet sees first. When you "change name servers" in your registrar's control panel, you're updating these.
If these point to the wrong servers, your domain is unreachable. Nothing else you configure matters until this is right.
In Your Zone File
Your authoritative name servers also contain NS records. These should match what's at your registrar. They serve two purposes:
- Completing the zone's declaration of its own authority
- Enabling subdomain delegation
When registrar and zone NS records don't match, resolution becomes unpredictable. Some queries work, some fail, and the inconsistency makes debugging maddening.
The Glue Record Problem
Here's a genuine paradox: What if your name servers are hosted on your own domain?
To resolve example.com, you need to ask ns1.example.com. But to find ns1.example.com, you need to resolve example.com first. Chicken and egg.
Glue records solve this. They're IP addresses stored directly in the TLD registry, bypassing the normal resolution process:
Now the TLD servers can return both the NS records and the IP addresses needed to reach them, breaking the circular dependency.
Subdomain Delegation
NS records let you hand off pieces of your domain to entirely different servers:
Shopify's servers now control shop.example.com and everything beneath it. Your servers handle the rest. The parent zone simply says "ask Shopify about shop."
This enables:
- SaaS integration: Service providers manage their subdomains directly
- Organizational boundaries: Departments control their own DNS
- Environment isolation: Separate name servers for production, staging, development
Best Practices
Use multiple name servers on different networks. The DNS specification recommends name servers in different geographic locations. If one data center goes down, others keep answering. Modern providers use anycast to advertise the same IP from multiple locations worldwide.
Keep records consistent. NS records at your registrar must match those in your zone. Mismatches cause intermittent failures—the worst kind to debug.
Plan TTL for migrations. NS records typically have 24-48 hour TTLs. Before switching DNS providers, lower the TTL several days in advance so the change propagates faster.
Never point NS records to CNAMEs. NS records must resolve directly to A or AAAA records. CNAME targets violate DNS specifications and cause resolution failures.
Key Takeaways
- NS records delegate authority by answering "who should I ask about this domain?"
- The delegation chain flows from root servers → TLD servers → your authoritative servers
- NS records exist in two places: the TLD registry (via your registrar) and your zone file—keep them synchronized
- Glue records break the circular dependency when name servers are on their own domain
- Subdomain delegation lets different servers manage different parts of your domain
- Multiple NS records on different networks provide redundancy against outages
Frequently Asked Questions About NS Records
Was this page helpful?