NS Lookup Guide: Find a Domain's Name Servers

Every domain name depends on a small set of servers that answer questions about it: what address its website lives at, where its mail goes, and which other records exist. Those servers are called name servers, and the NS records of a domain name them. The NS Lookup reads a domain's NS records and presents them, so you can see who is authoritative for the domain and whether the delegation is consistent. It is a format and consistency check on the records you supply or that a lookup returns, describing that input rather than performing a live DNS query itself, and its report should be read as a snapshot of those records, not as a guarantee about the domain's current live state.

NS records work through delegation. When you register a domain, you tell the registrar which name servers are authoritative for it, and the registrar publishes that delegation in the parent zone, the registry for the domain's ending. When someone looks up the domain, resolvers follow the delegation to those name servers and ask them for the actual records. A healthy setup has at least two name servers, usually from the same provider but on different networks, so that one failure does not silence the domain. The name servers listed at the registrar and the name servers listed inside the domain's own zone must agree: if the registrar says one set of servers is authoritative while the zone itself names a different set, resolvers receive conflicting answers, and the domain's behaviour becomes unpredictable, with some visitors reaching the right site and others reaching nothing.

Reading an NS result means checking consistency in several places. First, are there at least two name servers, and do they respond? A single name server is a single point of failure for the entire domain, including its website and its email. Second, do the registrar's delegation and the zone's own NS records match? A mismatch is one of the most common causes of a domain that works for some people and fails for others, because different resolvers may follow different delegations. Third, do the name server names themselves resolve to addresses? A name server named in a record that does not resolve is unreachable, and queries sent to it will time out before falling back to the next server, causing slow lookups. Fourth, do all the listed name servers serve the same records? If one server has outdated records, some visitors will receive old addresses, which produces the maddening symptom of a site that works on one network and fails on another.

Worked example

Take a sample domain, with values clearly labelled as an illustration. An NS lookup returns two name servers: ns1.exampledns.com and ns2.exampledns.com, and the registrar's delegation lists the same two names, so delegation and zone agree. The owner then migrates DNS to a new provider, which assigns ns1.newdns.com and ns2.newdns.com, and updates the zone but forgets to update the registrar. A new lookup now shows a mismatch: the registrar still delegates to the old pair, while the zone names the new pair. Visitors whose resolvers follow the registrar's delegation reach the old servers, which may still serve stale records or nothing at all, while visitors who reach the new servers get the current records. Suppose roughly half of queries follow each path: about 50 percent of visitors see the current site and about 50 percent see stale or failing results, which matches the owner's report that "the site works for some people and not for others". The fix is to update the registrar's delegation to the new pair and wait for the old delegation to expire from caches, a period governed by the time-to-live values involved, typically up to 48 hours for registrar changes to propagate fully. The lesson is that a DNS migration has two halves, the zone and the delegation, and updating only one creates a split-brain domain.

Mistakes to avoid

The first mistake is updating DNS records at a new provider without updating the registrar's delegation, which leaves half the internet asking the old servers. The second is running a domain on a single name server, so one failure silences the website and email together. The third is assuming a domain works because it works on your own network, when your resolver may be using cached or different records from those other networks see. The fourth is changing name servers during a launch or a migration without allowing propagation time, which turns a planned change into an outage for visitors with cached delegations. The fifth is including private details in a troubleshooting note alongside NS records: name server names are public by design, but passwords, account credentials, and internal addresses should never accompany them.

Putting it into practice

Check a domain's NS records after any DNS migration or provider change, when a site works for some visitors and not others, and before launching a new domain. Confirm that the registrar's delegation matches the zone's records, that at least two servers are listed, and that each server name resolves. For related tools, the DNS Lookup covers the wider record set, the MX Lookup shows where the domain's mail goes, and the companion guide on the DNS Lookup explains DNS records in depth. Name servers are the signposts of the domain system, and when the signposts disagree, every journey that depends on them becomes a gamble.

Key points

  • NS records name the servers authoritative for a domain, and resolvers follow the registrar's delegation to reach them
  • The registrar's delegation and the zone's own NS records must match, or visitors get conflicting answers
  • Run at least two name servers so one failure does not silence the domain's website and email together
  • A DNS migration has two halves, zone and delegation, and updating only one creates a split-brain domain

In short: check delegation against zone, keep at least two working name servers, allow propagation time after changes, and re-check after every migration.