NS Records Explained: Nameservers and Delegation

An NS record (short for nameserver record) tells the internet which nameservers are authoritative for a domain, meaning which servers hold the real DNS records and answer queries for it. When a resolver wants to look up your website, MX, or any other record, the NS records are what point it to the correct servers. Their core function is delegation: handing responsibility for a zone over to a specific set of nameservers. This is one of the foundational ideas of the domain name system, described in RFC 1034. For the full picture of how it fits alongside A, MX, TXT, and other types, see our DNS records explained pillar guide.

Because NS records sit at the boundary between you and the rest of the DNS, getting them right matters more than almost any other record. Get them wrong or inconsistent, and none of your other records will resolve. Nameserver changes are also subject to caching delays, which we cover in DNS propagation explained.

What a nameserver actually is

A nameserver is a server that stores DNS records for one or more zones and responds to queries about them. Authoritative nameservers are the source of truth for your domain; recursive resolvers, like the one your ISP runs, ask those authoritative servers and cache the answers. The record format itself, including how an NS record is encoded in a response, is laid out in RFC 1035. NS records are how the DNS knows which authoritative nameservers to trust for a given domain.

When you sign up with a DNS host or use your registrar's DNS, you are assigned a set of nameservers. A typical set looks like this:

Nameserver	Role
ns1.example-dns.com	Primary authoritative nameserver
ns2.example-dns.com	Secondary authoritative nameserver

The delegation chain: root to TLD to you

DNS resolves names by walking down a hierarchy:

1. The root nameservers know which servers are authoritative for each top-level domain (TLD) such as .com, .org, or .app.
2. The TLD nameservers know which nameservers are authoritative for each domain registered under them.
3. Your nameservers know the actual records for your domain.

At each step, NS records perform the handoff. The TLD registry publishes NS records that delegate your domain to your chosen nameservers, and from there your nameservers answer for everything inside your zone.

Registry delegation vs in-zone NS records

This is the part that confuses many people. There are two places NS records appear:

• The delegation set held by the TLD registry, set through your registrar. This is what the rest of the world follows to find your domain.
• The NS records inside your own zone, served by your authoritative nameservers.

Ideally these two sets match exactly. The registry delegation is authoritative for routing queries to you; the in-zone NS records confirm the same answer once a resolver reaches your servers. A mismatch (called a lame delegation when servers do not agree or do not answer) can cause intermittent failures that are hard to diagnose, since some resolvers may get a working answer while others do not.

You change the registry delegation at your registrar, not in your zone file. Editing only the in-zone NS records without updating the registrar will not move your domain.

Why you usually see at least two nameservers

Most registries require at least two nameservers, and using two or more is the standard recommendation. It comes down to redundancy. If one nameserver is unreachable, resolvers can query another and your domain keeps resolving. Spread those nameservers across different networks or locations and you further reduce the chance that a single outage takes your domain offline.

What breaks when NS records are wrong

NS problems tend to cause total or partial outages rather than subtle bugs:

• Pointing to nameservers that do not host your zone means resolvers get no usable records, so the whole domain fails.
• A mismatch between registry delegation and in-zone NS records can cause inconsistent resolution across different resolvers.
• Removing or misconfiguring one of several nameservers reduces redundancy and can cause sporadic timeouts.

Because NS records gate everything else, always verify them after any migration or DNS host change.

A note on glue records

When your nameservers live inside the same domain they serve (for example, ns1.yourdomain.com serving yourdomain.com), there is a chicken-and-egg problem: to find the nameserver you would need to resolve a name that the nameserver itself is supposed to answer. Glue records solve this. The TLD registry stores the IP addresses of those in-domain nameservers alongside the delegation, so resolvers can reach them directly. If you use a third-party DNS provider, glue is handled for you; you typically only deal with it when running nameservers under your own domain.

How to verify your nameservers

You can confirm both the delegation and the records that answer for your domain with our DNS tool. It looks up the NS records returned for your domain so you can compare them against what you set at your registrar and spot mismatches before they cause problems. Pair this with how to check DNS records to review the rest of your zone in one place.

Run a free DNS check now at domainintel.app to see exactly which nameservers are authoritative for your domain and whether your delegation is set up correctly.