NS Record Lookup: Checking Nameserver Configuration

What NS Records Mean

NS (Name Server) records, defined in RFC 1035 Section 3.3.11, declare which servers are authoritative for a DNS zone. When a resolver needs to look up any record for example.com, it first finds the NS records to learn which servers hold the zone data, then queries one of those servers directly. NS records are the foundation of DNS delegation as described in RFC 1034 Section 4.2 — they are how the parent zone (like .com) hands off responsibility to your nameservers.

Every domain typically has at least two NS records. While one is technically sufficient at the protocol level, two or more are strongly recommended and often required by registry or provider policy: if one nameserver goes down, the other answers queries. Most configurations use two to four nameservers, often on different networks for resilience.

Authoritative vs. Recursive Nameservers

NS records point to authoritative nameservers — the servers that hold your actual DNS zone file. These are different from recursive resolvers like 8.8.8.8 or 1.1.1.1, which cache and forward queries on behalf of clients.

When you change your DNS hosting provider, you update the NS records at your registrar to point to the new provider's authoritative servers. Until that delegation change propagates (governed by the NS record TTL at the parent zone), some resolvers may still query the old nameservers.

Checking Delegation Consistency

NS records exist in two places: at the parent zone (the TLD registry) and in your own zone. These should match for consistent resolution. A mismatch between the two — called a delegation inconsistency — can cause intermittent resolution failures. The parent zone's NS records tell resolvers where to go. Your zone's NS records confirm "yes, I am authoritative for this zone."

The mxio NS Lookup shows the NS records returned for your domain. For a deeper analysis that compares parent-zone delegation with your zone's own NS records and checks each nameserver for consistency, use the Delegation Health tool.

Common NS Record Issues

Lame delegation. The parent zone delegates to a nameserver that does not actually serve your zone. Queries to that server return SERVFAIL or REFUSED. This typically happens after switching DNS providers without updating all NS records at the registrar, or when a hosting provider decommissions a nameserver.

Mismatched NS records. The NS records at the registrar list different servers than the NS records in your zone. Some resolvers follow the parent delegation, others follow the zone's own NS set, and the result is inconsistent resolution across the internet.

Missing glue records. If your nameservers are within your own domain (e.g., ns1.example.com is a nameserver for example.com), the parent zone needs glue records — A records for the nameserver hostnames, as described in RFC 1034 Section 4.2.1. Without glue, resolvers hit a circular dependency: they need to resolve ns1.example.com to find the nameserver for example.com, but ns1.example.com is inside the zone they are trying to reach.

Stale NS records after migration. After moving to a new DNS provider, the old NS records may linger at the registrar if the update was incomplete. Some queries succeed (hitting the new servers), others fail (hitting the old ones that no longer serve your zone).

Verifying Your Nameservers

Use the mxio NS Lookup to see which nameservers are published for any domain. If you suspect delegation issues, follow up with the Delegation Health tool for a full consistency check between the parent zone and your authoritative servers.

Look up NS records for your domain