What Is an NS Record, and How Does It Delegate a Domain?

When you change your domain's "nameservers" at your registrar, you're editing NS records — and that single change decides which company's servers answer every DNS question about your domain. Get it right, and every other record you create starts working. Get it wrong, and nothing in your zone matters, because the internet is asking the wrong servers. NS records are the mechanism that makes DNS a distributed system rather than one giant database: each zone points to the servers responsible for the zone below it.

This article explains what an NS record is, how delegation works from the root down to your domain, the difference between the NS records at your registrar and the ones in your zone, how to delegate a subdomain to a different provider, and how to diagnose broken delegation. For the practical registrar steps, see how to update nameservers for a domain.

What Is an NS Record?

An NS record (name server record), defined in RFC 1035, specifies a server that is authoritative for a DNS zone. "Authoritative" means it holds the official records for that zone and answers queries about it directly, rather than looking them up elsewhere. If you're unsure of that distinction, see authoritative vs. recursive DNS servers.

A domain typically has two or more NS records:

example.com.  86400  IN  NS  ns1.dnsprovider.example.
example.com.  86400  IN  NS  ns2.dnsprovider.example.

Each record's value is a hostname, never an IP address. Resolvers look up that hostname's A or AAAA record to find the server's address.

NS records serve two purposes:

1. Delegation. In the parent zone, NS records say "the zone example.com is handled by these servers — go ask them."
2. Authority. In the zone itself, NS records declare which servers are authoritative for it.

How Delegation Works

DNS is a tree. The root zone sits at the top, top-level domains like .com and .org sit below it, and your domain sits below its TLD. No single server holds the whole tree. Instead, each level contains NS records that delegate the next level down.

When a recursive resolver needs www.example.com and has nothing cached, it follows the delegation chain:

1. The resolver asks a root server. The root servers don't know about example.com, but they hold NS records for .com. They respond with a referral: "ask these .com servers."
2. The resolver asks a .com server. The TLD servers don't hold your website's records either, but they hold NS records for example.com. They refer the resolver to your provider's name servers.
3. The resolver asks your name servers. These are authoritative for example.com, so they return the actual answer.

You can watch this happen with dig +trace, which performs the resolution step by step from the root:

dig +trace www.example.com

The output shows each referral in turn: the root servers' NS records for com., the .com servers' NS records for example.com., and finally the answer from your authoritative servers. It's the single most useful command for diagnosing delegation problems.

Seeing the referral directly

You can ask a .com server directly what it thinks your delegation is:

dig NS example.com @a.gtld-servers.net +norecurse

The response has no ANSWER section. Instead, the AUTHORITY section lists the NS records for example.com as stored in the .com zone — the delegation your registrar published. That's exactly what resolvers worldwide see.

Parent NS Records vs. Child NS Records

This is where most confusion comes from. A delegated domain's NS records exist in two places:

	Parent-side (delegation) NS	Child-side (authoritative) NS
Where they live	In the TLD zone, such as .com	In your own zone, at the apex
Who edits them	You, through your registrar	You, through your DNS host (often automatic)
What they do	Tell resolvers where to find your zone	Declare which servers are authoritative
Typical TTL	Set by the TLD operator (two days is common for .com)	Set in your zone

When you "change nameservers" at your registrar, you're changing the parent-side records. Your registrar sends them to the TLD registry, which publishes them in the TLD zone. That's why the registrar and your DNS host can be completely different companies — a distinction covered in domain registrar vs. DNS host.

The two sets should match. If they don't:

• Resolvers that follow the parent's delegation may reach different servers than those your zone advertises.
• Some resolvers prefer the child's NS set once they've reached your servers, so traffic can split unpredictably.
• During a provider migration, a mismatch can leave part of the internet using your old provider.

Check both sides and compare:

# Parent side: what the .com registry publishes
dig NS example.com @a.gtld-servers.net +norecurse

# Child side: what your own authoritative servers say
dig NS example.com @ns1.dnsprovider.example +short

The first command shows the delegation in the AUTHORITY section; the second shows your zone's own NS records. The hostnames should be identical.

Glue records

There's a chicken-and-egg problem when your name servers are inside the domain they serve. If example.com uses ns1.example.com, a resolver can't look up ns1.example.com without first knowing where example.com's name servers are. The fix is glue: the parent zone publishes the IP addresses of those name servers alongside the NS records. The details are in what glue records are.

Delegating a Subdomain

NS records aren't only for whole domains. You can delegate any subdomain to a different set of name servers by adding NS records for it in your zone. This is common when:

• A development team manages dev.example.com in a cloud provider's DNS.
• A marketing platform needs full control of go.example.com.
• A Kubernetes cluster updates records in its own zone through an automation tool.

To delegate dev.example.com to another provider, add NS records for it in the example.com zone:

$ORIGIN example.com.

dev   3600  IN  NS  ns-101.cloudprovider.example.
dev   3600  IN  NS  ns-202.cloudprovider.example.

Then create the dev.example.com zone at the other provider. From that point, every query for anything under dev.example.com is referred to those servers, and records for it in your main zone are ignored.

Two rules matter here:

1. A delegated name can't have other records in the parent zone. Once dev has NS records, you can't also put an A record for dev in the example.com zone — it belongs to the child zone now. (Glue addresses for in-zone name servers are the exception.)
2. Delegation applies to the whole subtree. api.dev.example.com and everything else under dev goes to the child zone.

On AWS Route 53, you'd create a hosted zone for dev.example.com, note the four name servers Route 53 assigns, and add them to the parent zone:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789PARENT \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "dev.example.com",
        "Type": "NS",
        "TTL": 3600,
        "ResourceRecords": [
          { "Value": "ns-101.awsdns-12.com" },
          { "Value": "ns-202.awsdns-25.net" },
          { "Value": "ns-303.awsdns-37.org" },
          { "Value": "ns-404.awsdns-50.co.uk" }
        ]
      }
    }]
  }'

This writes the delegation into the parent hosted zone. Replace the values with the exact name servers Route 53 assigned to your child zone — they differ for every hosted zone.

How to Check NS Records

The quickest check:

dig NS example.com +short

This returns the NS records your resolver currently sees. With other tools:

nslookup -type=NS example.com

Resolve-DnsName -Name example.com -Type NS

To confirm every listed name server actually answers authoritatively, query each one directly:

for ns in $(dig NS example.com +short); do
  echo "== $ns"
  dig SOA example.com @"$ns" +norecurse +short
done

Each server should return the same SOA record. A timeout, a REFUSED response, or an empty answer means that server isn't serving the zone — a condition called lame delegation.

Here's the same check in Python, which also flags responses without the authoritative-answer (AA) flag:

import dns.flags
import dns.message
import dns.query
import dns.resolver

domain = "example.com"

for ns in dns.resolver.resolve(domain, "NS"):
    ns_name = str(ns.target)
    try:
        ns_ip = str(dns.resolver.resolve(ns_name, "A")[0])
        query = dns.message.make_query(domain, "SOA")
        response = dns.query.udp(query, ns_ip, timeout=3)
        authoritative = bool(response.flags & dns.flags.AA)
        status = "OK" if authoritative and response.answer else "LAME"
    except Exception as exc:
        status = f"ERROR ({exc.__class__.__name__})"
    print(f"{ns_name:35} {status}")

The script sends an SOA query straight to each name server and checks that it answers with the AA flag set. Any server marked LAME or ERROR needs fixing at your DNS host or registrar.

Common Mistakes and Best Practices

1. Only one name server. Always use at least two, ideally on different networks. Registries for many TLDs require a minimum of two. For even more resilience, see using multiple DNS providers for redundancy.
2. Pointing NS at an IP address. NS values must be hostnames. If your dashboard lets you enter an IP, it's wrong.
3. Pointing NS at a CNAME. RFC 2181 forbids an NS record from pointing to an alias. Use the name server's real hostname.
4. Lame delegation after a migration. You update the registrar to a new provider but forget to create the zone there, or you delete the zone at the old provider before the parent's NS TTL has expired. Keep the old zone running until the change has fully propagated.
5. Parent and child NS sets that don't match. Update both when you change providers. Most managed providers set the child NS records automatically, but check after any migration.
6. Forgetting the long parent TTL. TLD delegations often have TTLs of a day or two, so nameserver changes take longer to settle than ordinary record edits. Plan for it — see DNS propagation delay.
7. Leaving abandoned subdomain delegations. An NS delegation to a provider where you've deleted the zone can, on some platforms, let someone else create that zone and take control of the subdomain. Remove delegations you no longer use.

---

NS Record FAQ

Conclusion

NS records are what turn DNS from a single directory into a hierarchy of independent zones. Each level holds NS records that delegate responsibility for the next level down, from the root to the TLD to your domain, and from your domain to any subdomain you choose to hand off. Everything else in your zone depends on that chain being correct.

In practice, a healthy delegation comes down to a handful of checks: at least two name servers, listed as hostnames rather than IPs or CNAMEs, matching between your registrar and your zone, and each one actually answering authoritatively. Use dig +trace to follow the chain, query each server directly to catch lame delegation, and plan around the long TTLs on parent-side records whenever you change providers.

Here are some useful references for going deeper on NS records and delegation:

1. RFC 1034: Domain Names - Concepts and Facilities — explains zones, delegation, and how resolvers follow referrals.
2. RFC 1035: Domain Names - Implementation and Specification — defines the NS record format.
3. RFC 2181: Clarifications to the DNS Specification — clarifies NS record rules, including the prohibition on aliases.
4. Cloudflare Learning Center: What is a DNS NS record? — an overview of NS records and delegation.
5. AWS Documentation: Routing traffic for subdomains — how to delegate a subdomain to a separate Route 53 hosted zone.