An NS lookup shows which nameservers are authoritative for a domain - the servers that hold and answer for its DNS zone, as distinct from the registrar that just registered the name.
What an NS record actually points to
A Nameserver (NS) record delegates authority for a zone to a specific set of servers. When a resolver needs to find any record for example.com, it first asks the root servers, then the .com TLD servers, and follows the NS records at each step until it reaches the servers listed for example.com itself. Those servers, and only those servers, are trusted to answer authoritatively for that zone.
NS records live at two places that are easy to confuse. The parent zone (the TLD, e.g. .com) holds a delegation: NS records pointing at the child zone's nameservers. The child zone (example.com itself) holds its own copy of the same NS records, published from inside the zone. A lookup tool queries the second copy - what the zone says about itself - not the delegation held by the registry.
- Nameserver hostnames must resolve to an A or AAAA record; RFC 1035 does not permit a CNAME target here
- A domain should have at least two NS records at different network locations, per RFC 2182 resilience guidance
- Nameservers listed on the delegation but unreachable can cause intermittent resolution failures for the whole domain
Registrar NS vs zone NS: two records, one point of failure
Changing "nameservers" in a registrar control panel edits the parent-zone delegation - it tells the TLD servers who to send resolvers to next. The zone itself, hosted wherever those nameservers actually run, must independently publish matching NS records for itself. If the two disagree (a stale zone file still lists an old provider, or the registrar delegation was updated but the zone was not), resolvers can get inconsistent answers depending on which copy they consult and cache.
This split matters most during a DNS provider migration: the delegation at the registrar and the NS records inside the new zone both need updating, and there is no atomic way to do both at once. A short overlap window where old and new nameservers are both listed is the standard way to avoid a gap.
Glue records: why some NS entries need a helping hand
A glue record is an A or AAAA record that the parent zone serves alongside an NS delegation, needed only when a nameserver's hostname is inside the domain it serves - for example ns1.example.com as a nameserver for example.com. Without glue, resolving ns1.example.com would require asking example.com's nameservers, which is circular. The parent zone sidesteps the loop by attaching the IP address directly to the delegation response.
Nameservers hosted on a different domain (ns1.dnsprovider.com serving example.com) need no glue: their address resolves independently through the provider's own zone. Glue is specifically a parent-zone artifact and does not appear in a lookup against the child zone itself - an NS lookup on example.com shows the nameserver names, not the glue IPs behind them.
Reading the results
The tool returns two things worth distinguishing. A dedicated "Nameservers" summary lists the hostnames the resolver used to answer the query - this comes back on every lookup regardless of record type. The NS record list underneath, when NS is the queried type, shows each nameserver as its own entry: record type, the queried domain name, and the nameserver hostname as the value. A missing NS list with an empty or short nameserver summary usually means the domain has no delegation at all, or the resolver could not reach any authoritative server.
| Field | Meaning |
|---|---|
| Nameservers (summary) | Hostnames the resolver actually used to answer this query |
| Type | Always NS for this record set |
| Value | The authoritative nameserver hostname, e.g. ns1.example.com |
FAQ
Why do I see different nameservers than the ones I set at my registrar?
A lookup tool queries the zone's own published NS records, not the registrar's delegation. If a change was made recently, the zone itself may not have been updated to match, or cached answers from before the change are still being served upstream.
How many nameservers should a domain have?
RFC 2182 recommends at least two, ideally on separate networks and in separate physical locations, so that one outage does not take the whole domain offline. Most managed DNS providers publish four by default.
Can two domains share the same nameservers?
Yes. Nameservers are just servers configured to answer for one or more zones; a single provider commonly serves NS records for many unrelated customer domains from the same server set.
What does it mean if an NS lookup returns no records?
The domain has no delegation published, the TLD registry has no NS records on file for it, or every listed nameserver failed to respond. It does not necessarily mean the domain is unregistered - check WHOIS separately to confirm registration status.
Do subdomains need their own NS records?
Only if the subdomain is delegated to a different set of nameservers than its parent - for example when a third-party service manages a subdomain independently. Without an explicit delegation, a subdomain simply inherits the parent zone's nameservers.
Related tools
- Run a fuller DNS health audit that includes NS consistency alongside other record types
- Check whether an NS change has propagated to resolvers around the world
- Confirm registrar-level delegation and registration status for the same domain
- Look up PTR records for the IP addresses behind a nameserver hostname