Name server check

Looks up the NS set and the IPv4 and IPv6 addresses of up to eight name servers, and reports a single server, servers that do not resolve, all addresses in one /24 or /48, one top-level domain for all names, and servers inside the zone that need glue. The servers themselves are not contacted.

Updated 2026-10-27

Free, no account, nothing is stored

What this tool checks

The NS set is asked for through public resolvers, then the IPv4 and IPv6 addresses of up to eight name servers:

  • Count: a single name server.
  • Resolution: a name server whose name has no address (NS_UNRESOLVABLE).
  • Diversity: all addresses in one /24 (IPv4) and one /48 (IPv6), and all names under one top-level domain.
  • Glue: name servers inside the zone.

How to read the result

Each name server is listed with its addresses. Diversity is judged from the addresses alone; two providers can share a network, and one provider can span several.

Limitations

  • Network diversity is a heuristic from the address prefixes; operator and ASN are not looked up.
  • At most eight name servers are resolved.

Use it from code

API reference for Name server check

curl -i "https://api.lookproof.dev/v1/dns/ns?domain=example.com"

A request without payment is answered with 402 Payment Required and the exact price. See the API reference.

Limits

InputDomain
Deadline10 seconds
FreshnessUp to 5 minutes, never longer than the record TTL
Price$0.01 per check

Findings this tool can report

Name servers (6)
Check (1)
DNS (3)

Frequently asked questions

How many name servers should a zone have?

At least two, in different networks (RFC 1034 and RFC 2182). With one server, or several in one /24, a single failure takes the whole domain offline: NS_SINGLE and NS_SAME_NETWORK.

What does in-bailiwick mean?

A name server such as ns1.example.com that lies inside the zone it serves. It can only be found through glue records at the parent zone, which your registrar publishes. NS_IN_BAILIWICK reminds you to keep the glue in step.

Does the tool query the name servers directly?

No. Everything goes through public resolvers, so lame delegations (a server that does not answer for the zone) and differences between the parent's and the zone's NS sets are not detected.