DNS Tools
DELEGATION DIAGNOSTICS

NS Lookup

See which name servers are authoritative for a domain, whether the parent zone and the zone itself agree, and whether every server really answers for the zone.

Run NS delegation

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What NS records and delegation are

NS records name the servers that are authoritative for a zone. They exist in two places that must agree. The parent zone, for example the .com servers for example.com, holds the delegation: the list of name servers that the registrar has set, which is what resolvers follow first. The zone itself, on its own servers, publishes its own NS set. Everything else in your DNS depends on resolvers finding the right servers through this chain.

The tool works out the zone that contains the name you typed, reads the delegation from the parent, asks each authoritative server for its own NS set and SOA, and compares them. If you enter a host name that is not itself a delegation point, it analyses the zone that contains it and says so.

How to read the result

  • At least two name servers: a single name server is flagged as something to improve, since an outage there makes the whole zone unreachable once caches expire.
  • Network diversity: if every server address sits inside one network prefix (a /24 for IPv4, a /48 for IPv6), the tool says so. Servers on one prefix tend to fail together.
  • Parent and child match: a pass means the registrar delegation and the zone's own NS records list the same servers. A mismatch is reported as something to improve, because resolvers use the parent's list, while the zone owner believes the child's list applies.
  • No delegation at the parent: reported as a risk. The parent returns no NS for the zone, so the zone cannot be found at all, typical of an expired or unregistered domain, or one that was never delegated.
  • Lame servers: a server listed as authoritative that does not answer authoritatively for the zone. If every responding server is lame the result is a risk; if only some are, it is something to improve.
  • Glue: when a name server lives inside the zone it serves, resolvers need the parent to supply its address. The tool checks that such names resolve.
  • Alias or non-public targets: NS targets that are CNAMEs are not allowed, and servers that resolve only to private addresses are not queried.
  • SOA serial agreement: servers of one provider should report the same serial. Different serials across separate providers are expected and shown as informational.

Common delegation problems

  • Changed DNS provider but not the registrar: the zone was copied to the new provider, but the registrar still delegates to the old one, so the new records never get used.
  • Old provider switched off too early: lame servers appear when a provider stops serving the zone while it is still delegated.
  • Registrar and zone out of sync: the NS records inside the zone were edited but the delegation at the registrar was not, or the reverse.
  • In-zone servers without glue: ns1.example.com serving example.com needs glue at the parent; without it the delegation is circular.
  • Two servers, one network: redundancy on paper but one outage in practice.

How to change name servers safely

Changing delegation is one of the highest-impact edits in DNS, because resolvers cache the parent's NS set for a long time, often a day or more, and the registrar controls the TTL, not you. Treat it as a migration, not an edit.

The safe pattern is to build the complete zone at the new provider first, verify that every record matches, and keep the old provider serving the zone throughout. Only change the delegation at the registrar when the new servers answer correctly.

  1. Export the full zone from the old provider and import it at the new one.
  2. Query the new servers directly and compare every record with the old zone.
  3. Update the NS records at the registrar, in one change.
  4. Re-run this lookup: parent and child should agree, with no lame servers.
  5. Leave the old provider serving the zone for at least the parent's NS TTL, and longer if unsure.
  6. To roll back, restore the previous NS set at the registrar; the old zone must still be intact.

What this test cannot see

The tool queries at most eight authoritative servers, using one address per server, from one scanner. Anycast servers that behave differently elsewhere are not visible. It reads the delegation as the parent's servers return it, but it cannot see registrar-side settings such as locks or pending changes. A server that is reachable from this scanner may still be blocked from another network, and a server that is not reachable here may work elsewhere.

Frequently asked questions

What does 'lame delegation' mean?

A name server is listed for a zone but does not answer authoritatively for it, for example because the zone was removed from that server. Resolvers that choose it get no usable answer.

Why do the parent and the zone list different name servers?

Often one was updated and not the other. The parent's list controls where resolvers go, so a zone's own NS records alone do not move a domain between providers.

How many name servers should I have?

At least two, on different networks. The tool flags a single server and servers all inside one network prefix.

Why do SOA serials differ between servers?

Within one provider it often means a secondary has not yet caught up. Between different providers, independent serials are normal and shown as informational.

How long does a name server change take?

It depends on the NS TTL held at the parent, often a day or more. Keep both providers answering during that time.

Does this tool change anything?

No. It only reads DNS. Delegation is changed at your registrar.

Written by DNS Tools editorial · Last updated 2026-10-09