What is a DNS NS record?

An NS record is a DNS record that identifies the authoritative name servers for a DNS zone. NS stands for Name Server. When a resolver needs an answer for a domain, the DNS hierarchy uses NS records to find which servers are responsible for that zone.

For example, the parent zone for example.com delegates authority by listing the name servers for example.com. Those authoritative servers then answer questions about records inside the zone, such as A, AAAA, MX, TXT, CNAME, and other record types. Without correct NS records, the rest of the zone may be unreachable even if the individual records are written correctly.

NS records are sometimes confused with DNS hosting accounts. The account is where an operator manages records. The NS records are the public delegation that tells the internet which authoritative servers to ask. A domain can have a complete zone file in one provider's dashboard, but if the registrar delegates the domain to a different provider's name servers, the public internet will not use that zone file.

Delegation in plain terms

DNS is hierarchical. A resolver starts with knowledge of the root, follows delegation to a top-level domain such as .com, and then follows the NS records for the requested domain. Each delegation step tells the resolver where to ask next.

For a registered domain, the most important delegation is usually configured at the registrar. The registrar records which authoritative name servers are responsible for the domain. Those name servers should also publish matching NS records inside the zone itself. The parent-side delegation and the in-zone NS set should agree unless there is a deliberate migration in progress.

Some name servers need glue records. Glue is address information supplied by the parent zone when the name server lives inside the delegated domain. For example, if ns1.example.com is authoritative for example.com, a resolver may need an IP address for ns1.example.com before it can ask the example.com zone anything. Glue prevents that circular dependency.

What healthy NS configuration looks like

A healthy zone normally has at least two authoritative name servers. They should be reachable, synchronized, and operated in a way that avoids a single point of failure. The name servers may be spread across different networks or locations depending on the provider and the importance of the domain.

Consistency matters. Each authoritative server should return the same essential zone data, including SOA, NS, and important service records. Serial numbers in the SOA record can help indicate whether secondaries have received the latest zone version. A mismatch can cause different users to receive different answers depending on which name server their resolver reaches.

Availability also matters. Authoritative name servers should respond over UDP and TCP on port 53. TCP is not optional; it is needed for larger responses, DNSSEC, and fallback behavior. Firewalls that permit only UDP can create strange resolution failures.

Common mistakes with NS records

The most common mistake is changing records in the wrong DNS provider. This happens when a domain was moved between providers, but someone updates the old zone because it is still visible in a dashboard. Public resolution follows the delegated NS records, not the dashboard that looks familiar.

Another mistake is partial migration. Operators may add new name servers at the registrar but leave old in-zone NS records, stale glue, or old secondary servers. During propagation, resolvers can see mixed answers. If both old and new providers are not kept in sync, the same domain can appear to work for some users and fail for others.

Lame delegation is a serious failure mode. It occurs when a parent zone delegates to a name server that is not actually authoritative for the child zone. The server may be unreachable, may refuse queries, or may answer as if it does not host the zone. Lame delegation can slow resolution or break it entirely.

DNSSEC adds another layer. If a zone uses DNSSEC, NS changes may also require DS record changes at the parent. A mismatch between DS records and the new zone signing setup can make validating resolvers reject the domain, even when non-validating resolvers appear to work.

Security and ownership risks

NS records define who can answer for a domain. That makes them a high-value control point. If an attacker or unauthorized party changes delegation, they may be able to redirect web traffic, intercept some email flows, issue misleading DNS answers, or disrupt service.

Expired DNS hosting accounts can create takeover risk. If a domain remains delegated to a provider where the zone has been deleted, another party may be able to claim the zone depending on the provider's controls. Stale name server delegations should be removed when providers are retired.

Registrar security is part of NS security. Strong registrar account protection, multi-factor authentication, role separation, change notifications, and domain locks reduce the chance of unauthorized delegation changes. Monitoring should include both DNS answer changes and registrar-level name server changes.

Evaluating an NS record set

Start by querying the parent delegation and the authoritative zone. Confirm that the name servers listed by the registrar match the NS records returned by the zone. Then query each authoritative name server directly for SOA, NS, and a few critical records. The answers should be consistent.

Check reachability over UDP and TCP. Confirm that each name server returns authoritative answers for the zone and does not depend on recursion. Review glue records if the name servers sit under the same domain. For DNSSEC-enabled zones, validate DS and DNSKEY continuity before and after changes.

Operational teams should also know who owns the provider account for each delegated name server. A clean technical configuration can still be fragile if nobody knows how to change it during an incident.

Rollout checks for name server changes

Plan NS changes as a migration, not a quick edit. Build the full zone at the new provider before changing delegation. Lower relevant TTLs where possible, export the old zone, and compare important records such as website addresses, mail records, TXT authentication records, CAA records, and DNSSEC settings.

During cutover, update registrar delegation and monitor from multiple resolvers. Query both old and new authoritative servers while caches expire. Keep the old zone active and synchronized until the migration window is complete.

After cutover, remove stale delegations, old glue, and unused provider zones. Keep a record of the final authoritative name servers and who can administer them. NS records are small, but they determine the authority chain for every other DNS answer the domain relies on.

Related learning

• How to choose a domain name registrar
• What is a DNS A record?
• Common DNS issues and how to diagnose them