NS Record Check: How to Verify Nameserver Configuration

NS records are the delegation chain of DNS. They tell the internet which servers are authoritative for your domain, and every other record, A, MX, TXT, CNAME, all of them, depends on that delegation being correct. Get the NS records wrong and your entire domain goes dark: websites stop resolving, email bounces, API endpoints vanish, certificate validation fails. The failure mode is particularly cruel because it is intermittent. If only one of your nameservers is misconfigured, roughly half of all lookups succeed and the other half time out, producing the kind of flickering outage that is almost impossible to diagnose from application logs alone.

The reason NS problems are so persistent is that most teams configure nameservers once, during initial domain setup or a provider migration, and then never verify them again. Registrar panels, DNS providers, and zone files all show NS data, but they show different facets of it. The registrar holds the parent-zone delegation. The zone file holds the authoritative NS set. When those two disagree, the domain works most of the time but fails in ways that look random and are extremely frustrating to debug.

Quick check: Run your domain through the DNS Lookup Tool to see your current NS records, or use Domain Health for a full diagnostic that includes NS consistency verification.

What NS Records Actually Do

DNS is a hierarchical system, and NS records are the mechanism that makes hierarchy work. When a recursive resolver needs to look up `shop.example.com`, it does not ask a single database. It starts at the root, which delegates to the `.com` TLD servers via NS records, which in turn delegate to `example.com`'s authoritative servers via another set of NS records. That second delegation, the one stored in the `.com` zone, is the parent-side NS record set. It is what the registrar controls when you update nameservers in their panel.

Inside the zone itself, the authoritative server also publishes its own NS records. These zone-side NS records tell the resolver which servers consider themselves authoritative for the domain. In a healthy configuration, the parent-side and zone-side NS sets are identical. When they diverge, resolvers may follow the parent delegation to a server that does not know it is supposed to answer for the zone, or the zone may advertise a server that the parent never delegated to. Both situations cause resolution failures.

Glue Records and Why They Exist

There is a bootstrapping problem in DNS delegation. If `example.com` is served by `ns1.example.com`, the resolver needs to look up `ns1.example.com` to find the IP, but it needs to ask `example.com`'s nameserver to resolve that name, which is the server it is trying to find. Glue records break this circular dependency. They are A or AAAA records stored in the parent zone alongside the NS delegation, providing the IP address directly so the resolver does not need to make a separate lookup. Glue records are required when nameservers are under the domain they serve (in-bailiwick) and optional otherwise. Missing or stale glue records are a classic cause of resolution failures that only surface with certain resolvers or network paths.

How to Check NS Records

A proper NS record check requires verifying both sides of the delegation: what the parent zone says and what the zone itself says. Checking only one side misses the most common category of NS problems. The standard tool for this is `dig`, though DomScan's DNS Lookup Tool performs the same checks with a cleaner interface and stores historical results for comparison.

Checking the Zone-Side NS Records

The simplest check queries the zone's own NS records from a public resolver:

$ dig NS example.com +short
ns1.exampledns.net.
ns2.exampledns.net.
ns3.exampledns.net.

This returns the NS records as published in the zone file. The `+short` flag strips the response down to just the nameserver hostnames.

Checking the Parent-Side Delegation

To see what the parent zone (the registrar-level delegation) says, query the TLD servers directly using the `+trace` flag or by targeting a TLD server explicitly:

$ dig NS example.com +trace +nodnssec
;; Received 525 bytes from 198.41.0.4#53(a.root-servers.net)
example.com.    172800  IN  NS  ns1.exampledns.net.
example.com.    172800  IN  NS  ns2.exampledns.net.
example.com.    172800  IN  NS  ns3.exampledns.net.
;; Received 268 bytes from 192.5.6.30#53(a.gtld-servers.net)

The NS records shown in the referral section (from the gTLD server) are the parent-side delegation records. Compare them to the zone-side NS records. They should list the same set of nameservers. If they differ, you have a consistency problem that needs resolution.

Verifying Each Nameserver Responds

Once you know which servers are listed, verify that each one actually serves the zone. Query each nameserver directly:

$ dig @ns1.exampledns.net example.com SOA +short
ns1.exampledns.net. admin.example.com. 2024031501 3600 900 1209600 86400

$ dig @ns2.exampledns.net example.com SOA +short
ns1.exampledns.net. admin.example.com. 2024031501 3600 900 1209600 86400

$ dig @ns3.exampledns.net example.com SOA +short
;; connection timed out; no servers could be reached

In this example, `ns3.exampledns.net` does not respond. This is lame delegation: the NS record exists, but the server behind it does not serve the zone. Roughly one third of all DNS lookups for this domain will fail or time out, depending on which nameserver the resolver happens to pick.

Common NS Problems

NS misconfigurations tend to fall into a small number of recurring patterns. Most of them are introduced during provider migrations or initial setup and then persist for months because the domain "mostly works." The partially-working state is what makes them dangerous: the problem is real, the impact is measurable, but the symptoms are inconsistent enough that they get attributed to network issues or client-side problems.

Lame Delegation

Lame delegation is the single most common NS problem. An NS record points to a server that either does not respond at all or responds with REFUSED or SERVFAIL because it has no zone data for the domain. This happens most often after a DNS provider migration: the registrar is updated to point to the new nameservers, but one of the old servers is left in the NS set, or the new provider has not finished setting up all the listed servers. The result is that a fraction of all lookups fail, proportional to how many NS records are lame out of the total set.

Parent-Zone and Zone-Side Mismatch

When the NS records at the registrar (parent zone) differ from the NS records inside the zone file, resolvers receive conflicting signals. The parent delegation controls which servers the resolver contacts initially, but once those servers respond, the zone-side NS records may redirect the resolver to a different set of servers for subsequent queries. This creates inconsistent behavior depending on resolver caching state. Some lookups work, others fail, and the pattern shifts as caches expire and repopulate. The fix is straightforward: make both sets identical.

Missing Glue Records

If your nameservers are subdomains of the domain they serve (e.g., `ns1.example.com` serving `example.com`), the parent zone must contain glue A/AAAA records providing their IP addresses. Without glue, resolvers hit the circular dependency described earlier and the domain becomes unresolvable. Stale glue, where the IP address in the parent zone no longer matches the actual server IP, is equally problematic. The domain resolves to the old IP, which may be unresponsive or, worse, controlled by someone else.

Single Nameserver

RFC 1035 requires at least two nameservers for redundancy. A domain with a single NS record has no failover path. If that one server goes down, becomes unreachable from certain networks, or is temporarily overloaded, the domain disappears entirely. Many registrars enforce a minimum of two nameservers, but some do not. Even with two NS records, both pointing to the same physical host or the same network provides no meaningful redundancy. Effective NS redundancy means geographically and topologically separate servers.

NS Pointing to CNAME

RFC 1034 explicitly prohibits NS records from pointing to a CNAME alias. The target of an NS record must resolve directly to an A or AAAA record, not through an indirection chain. Some resolvers tolerate this violation, others reject it outright, and the behavior can change between resolver software versions. The result is another intermittent failure pattern: the domain resolves correctly from some networks and fails from others, depending entirely on which resolver implementation the client happens to be using.

NS Migration: Changing Nameservers Safely

Nameserver migrations are one of the highest-risk DNS operations because they affect every record in the zone at once. A botched NS migration does not just break one service; it breaks all of them simultaneously. The safe approach follows a strict sequence that accounts for propagation delays, cache lifetimes, and the possibility that something goes wrong at each step.

The Correct Migration Order

1. Replicate the full zone on the new nameservers. Every record that exists on the old servers must exist on the new ones before any delegation change. Verify with direct queries.
2. Lower the TTL on NS records and SOA minimum 48 hours before the migration. A TTL of 300 seconds (5 minutes) ensures caches refresh quickly once the switch happens.
3. Update the NS records at the registrar to point to the new servers. This changes the parent-zone delegation.
4. Wait at least 2x the old TTL. If NS records had a 24-hour TTL before you lowered it, some resolvers may have cached the old value. The safe window is twice whatever the longest cached TTL could be.
5. Verify from multiple vantage points: query public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) and confirm they return the new NS set and resolve records correctly.
6. Update the zone-side NS records on the new servers to match the new delegation, if they still reference the old servers.
7. Keep the old nameservers running and serving the zone for at least 48 hours after full propagation. Only retire them once you are confident no resolver is still following stale cached delegation.

The most common migration mistake is removing the zone from the old nameservers before propagation completes. During the transition window, some resolvers still have the old delegation cached and will query the old servers. If those servers no longer respond, those lookups fail. The old servers must continue serving the zone until all caches have expired.

NS Records and Security

Nameserver records are one of the most security-sensitive parts of DNS because controlling delegation means controlling all resolution for the domain. An attacker who can modify a domain's NS records, whether through registrar compromise, social engineering, or exploiting a domain transfer process, can redirect all traffic, intercept all email, and issue valid TLS certificates for the domain via automated validation. NS hijacking is not theoretical; it is the mechanism behind some of the most consequential domain takeovers in recent history.

Dangling NS and Subdomain Takeover

A particularly insidious attack vector involves dangling NS records: delegation to nameservers that the domain owner no longer controls. This happens most commonly when a team cancels a DNS hosting account but forgets to remove the NS delegation at the registrar. If the old DNS provider allows new customers to claim the same nameserver hostnames or zone, an attacker can register an account, create a zone for the victim's domain, and start serving arbitrary records. The parent-zone delegation still points to those servers, so resolvers follow it directly to attacker-controlled infrastructure. The domain owner may not even notice because the registrar panel still shows the old configuration.

This is the same class of vulnerability as dangling CNAME subdomain takeovers, but at the NS level the impact is total: the attacker controls the entire zone, not just a single hostname. Use DomScan's Reverse NS API to audit which domains are delegated to specific nameservers and identify delegation to decommissioned or third-party infrastructure that may be claimable.

DNSSEC and the NS Trust Chain

DNSSEC adds cryptographic signatures to DNS responses, creating a chain of trust from the root zone down to individual records. NS records sit at every link in that chain. When a parent zone signs a delegation, it includes a DS (Delegation Signer) record that cryptographically binds the parent's trust to the child zone's signing key. If the NS records change but the DS record is not updated to match the new zone's DNSSEC keys, validation-aware resolvers will reject all responses from the domain. This makes DNSSEC-signed NS migrations more complex: the new nameservers must be serving correctly signed responses, and the DS record at the parent must be updated to reference the new zone-signing key before (or simultaneously with) the NS delegation change.

For domains that do not use DNSSEC, NS records are entirely unauthenticated. A resolver accepts whatever NS referral the parent zone provides and whatever response the referred server returns, with no cryptographic verification. This is the fundamental trust gap that makes NS hijacking viable and DNSSEC adoption important for high-value domains.

Automating NS Checks

Manual NS verification works for a single domain but does not scale. If you manage dozens or hundreds of domains, you need automated checks that run continuously and alert on drift. DomScan's DNS Lookup API supports programmatic NS queries that can be integrated into monitoring pipelines, CI/CD checks, or periodic audits. The Domain Health endpoint combines NS consistency checks with DNS, SSL, and email authentication diagnostics in a single call.

• Query NS records via API and compare against a known-good baseline stored in your configuration management.
• Alert when parent-side and zone-side NS sets diverge, which indicates a delegation consistency problem.
• Flag any NS record where the target server fails to respond with a valid SOA for the zone.
• Track NS changes over time with DNS History to distinguish planned migrations from unexpected modifications.
• Use Reverse NS lookups to map provider concentration and identify single points of failure across your portfolio.

Independent references: Review RFC 1035 for the NS record specification and delegation model, and Cloudflare's DNS Record Types reference for operational guidance on NS configuration.

NS records are the foundation that every other DNS record depends on. A domain with correct A records, perfectly configured MX, valid SPF and DKIM, and a strong DMARC policy still breaks if the nameserver delegation is wrong. Checking NS records is not a one-time setup task. It is an ongoing operational responsibility that belongs in the same monitoring category as SSL expiration and WHOIS renewal: the kind of thing that is easy to verify, catastrophic to forget, and trivial to automate once you decide it matters.