NS (Name Server) records and nameserver health checks

1. NS records from your NameServers

This check lists the NS records returned directly by your authoritative nameservers for your domain. It shows how your own DNS servers describe the delegation.

Why this matters

The NS set published by your nameservers must be complete and consistent. If one server is missing, spelled incorrectly or announces a different NS list than the others, resolvers may randomly fail or keep outdated data in cache.

How DNSprobe tests it

DNSprobe sends NS queries directly to each of your authoritative nameservers and gathers the NS records they return. It normalises the hostnames, compares the sets and flags any discrepancy.

Common issues

• One nameserver returns a different NS list than the others.
• Some NS hostnames are misspelled or use a different domain.
• The NS set is incomplete compared to what is registered at the parent zone.

Best practices

• Ensure all authoritative servers return the exact same NS set.
• Use stable, descriptive hostnames for nameservers and avoid typos.
• Review NS changes carefully and monitor for drift between servers.

2. Public Resolver

This section simulates how large public resolvers see your NS records. It queries services like Cloudflare DNS, Google Public DNS, Quad9 and other major resolvers.

Why this matters

End users rarely talk directly to your authoritative nameservers. They usually rely on recursive resolvers operated by ISPs, public DNS providers or corporate networks. If these resolvers cache inconsistent data, your domain may behave differently for different users.

How DNSprobe tests it

DNSprobe sends NS queries to several public resolvers distributed around the world and compares their answers with your authoritative data. It highlights differences in NS sets, missing records or slow responders.

Common issues

• Some resolvers still see old NS records after a migration.
• A resolver cannot reach one of your nameservers and falls back to others.
• Different resolvers report different TTLs or partially divergent NS sets.

Best practices

• Plan NS changes with long lead times and lower TTLs before the switch.
• Monitor public resolvers after migrations to confirm consistent propagation.
• Use at least two independent DNS providers or clusters when possible.

3. Recursive Queries

This check verifies whether your authoritative nameservers allow recursive queries from the outside world.

Why this matters

Authoritative servers should normally not perform recursion for arbitrary clients. Open recursion can be abused for reflection and amplification attacks and may leak internal query patterns.

How DNSprobe tests it

DNSprobe sends queries for unrelated domains to your nameservers and observes whether they attempt to resolve them recursively. Behaviour is classified as recursion allowed or properly disabled.

Common issues

• Authoritative nameservers are configured as open resolvers for any IP on the Internet.
• Recursion is accidentally allowed from some networks due to ACL misconfiguration.
• Split-brain setups leak internal recursion to the public interface.

Best practices

• Disable recursion on all public-facing authoritative nameservers.
• Restrict any required recursion to internal resolvers behind firewalls.
• Regularly re-test your setup after software upgrades or config changes.

4. Same Glue

This test compares glue records at the parent zone with the A and AAAA records returned by your nameservers themselves.

Why this matters

Glue records provide the IP addresses of in-bailiwick nameservers to break circular dependencies. If glue differs from the real addresses, resolvers may send queries to the wrong server or fail to reach you.

How DNSprobe tests it

DNSprobe retrieves glue data from the parent zone and then resolves the NS hostnames directly from your authoritative servers. It compares IPs and flags mismatches or missing glue entries.

Common issues

• Parent glue still points to old IPs after a migration.
• IPv6 glue is missing while the nameserver advertises AAAA records.
• Glue exists for some nameservers but not for others in the same domain.

Best practices

• Update glue immediately whenever a nameserver IP changes.
• Keep IPv4 and IPv6 glue aligned with authoritative A/AAAA records.
• Avoid unnecessary glue for out-of-bailiwick nameservers.

5. NS Self-IP Consistency

This check verifies that nameservers correctly announce the same IP addresses that the parent and public resolvers use for them.

Why this matters

If a nameserver responds with an A or AAAA record that does not match its actual reachable IP, resolvers may cache wrong data and send queries to a dead address.

How DNSprobe tests it

DNSprobe queries each nameserver for its own hostname and compares the returned IPs with those seen at the parent zone and from external resolvers. Differences are highlighted.

Common issues

• Nameserver returns an outdated IP for its own hostname.
• Different addresses are returned depending on which server you ask.
• Internal addresses leak into public DNS answers.

Best practices

• Ensure each nameserver hosts a single, correct A/AAAA set for its hostname.
• Avoid mixing internal and external addressing in the same zone view.
• Check self-IP consistency after network changes or load-balancer updates.

6. Glue for NS records

This test focuses specifically on the presence and correctness of glue records required for in-bailiwick nameservers.

Why this matters

Without proper glue, resolvers may need extra queries to discover the IP of your nameservers, or in some cases fail completely when there is a circular dependency.

How DNSprobe tests it

DNSprobe inspects the parent zone for glue entries, checks their TTLs and compares them with the authoritative A/AAAA data published by your nameservers.

Common issues

• Glue completely missing for in-bailiwick nameservers.
• Glue present but pointing to deprecated infrastructure.
• Inconsistent TTLs causing slow convergence after changes.

Best practices

• Use glue only when technically necessary (in-bailiwick NS).
• Keep registrar and DNS provider procedures documented for glue updates.
• Verify glue after any registrar-side change or domain transfer.

7. Mismatched NS records

This check detects differences between the NS set advertised by the parent zone and the one returned by your authoritative nameservers.

Why this matters

Resolving a domain always starts from the parent zone. If the parent and child disagree on which nameservers are authoritative, some resolvers may never contact all of your servers.

How DNSprobe tests it

DNSprobe collects the NS list from the parent and from your nameservers, then compares hostnames one by one, highlighting missing, extra or mismatched entries.

Common issues

• Parent lists nameservers that no longer appear in the child zone.
• Child zone announces additional NS that the parent does not know about.
• Typos or case differences lead to effectively distinct hostnames.

Best practices

• Keep parent and child NS lists strictly aligned.
• When adding or removing a nameserver, update both registrar and zone.
• Re-run DNSprobe after changes to confirm there is no mismatch.

8. DNS servers responded

This test simply verifies that every configured nameserver actually responds to queries within a reasonable time.

Why this matters

A non-responsive nameserver still listed in NS records can cause random timeouts, as some resolvers will keep trying it before failing over to others.

How DNSprobe tests it

DNSprobe sends queries to each nameserver and measures latency and response codes. Servers that do not respond or send errors are highlighted.

Common issues

• A decommissioned server is still present in NS records.
• Firewalls or rate limiting block queries from some networks.
• Anycast or load-balancing misconfigurations causing intermittent failures.

Best practices

• Remove dead nameservers from NS records quickly.
• Monitor DNS availability and latency from multiple regions.
• Use health checks when running anycast or load-balanced DNS.

9. Name of nameservers are valid

This check validates that nameserver hostnames follow DNS rules and point to valid, routable addresses.

Why this matters

Invalid hostnames or records pointing to private or reserved IP space can break resolution or leak information about your internal network.

How DNSprobe tests it

DNSprobe checks the syntax of NS hostnames, then resolves them and verifies that IPs are public and correctly formatted.

Common issues

• Hostnames using invalid characters or labels.
• Nameservers pointing to private or RFC1918 addresses.
• Nameservers hosted under domains that no longer exist.

Best practices

• Use fully qualified, well-structured hostnames under stable domains.
• Avoid publishing internal addressing schemes in public DNS.
• Periodically revalidate NS hostnames after infrastructure changes.

10. Multiple Nameservers

This test counts how many distinct nameservers are configured for your domain and evaluates their diversity.

Why this matters

Running a single nameserver creates a single point of failure. Having at least two, and ideally more, improves resilience against outages, maintenance and routing issues.

How DNSprobe tests it

DNSprobe counts unique NS hostnames and IPs, then warns if you only have one or if all servers are effectively the same machine.

Common issues

• Only one authoritative nameserver configured.
• Multiple NS hostnames pointing to the same physical server.
• All nameservers hosted in the same datacenter or rack.

Best practices

• Run at least two independent nameservers for every domain.
• Distribute them across different networks and locations.
• Consider using a secondary DNS provider for additional redundancy.

11. Nameservers are lame

This check detects lame delegations, where a listed nameserver does not serve authoritative data for your domain.

Why this matters

A lame nameserver increases latency and failure rates because resolvers will query it, get no useful answer, and only then try another server.

How DNSprobe tests it

DNSprobe queries each nameserver for SOA and NS records of your domain and verifies that it responds authoritatively with correct data.

Common issues

• Delegation left in place after moving the zone to a new provider.
• Secondary server misconfigured or never properly added as a slave.
• Access lists blocking authoritative answers for some clients.

Best practices

• Ensure every listed NS hosts the zone and answers authoritatively.
• Remove legacy providers from the NS set once migration is complete.
• Monitor for lame delegations after registrar or provider changes.

12. Missing nameservers reported by parent

This check highlights nameservers present in your child zone but not registered at the parent.

Why this matters

Resolvers start at the parent zone. If some nameservers are only known in the child zone, many resolvers may never use them, reducing redundancy.

How DNSprobe tests it

DNSprobe compares the NS list from the parent with the one from your authoritative nameservers and lists servers that exist only in the child zone.

Common issues

• New nameserver added to the zone but not to the registrar.
• Temporary testing NS left in the child zone only.
• Registrar limits preventing the full NS set from being registered.

Best practices

• Keep parent and child NS lists aligned at all times.
• Update the registrar whenever you add or remove a nameserver.
• Avoid using unregistered NS for production traffic.

13. Missing nameservers reported by your nameservers

This check detects nameservers listed at the parent but absent from the child zone.

Why this matters

If the parent refers to nameservers that do not list themselves as authoritative in the zone, resolvers may see contradictory information and experience timeouts.

How DNSprobe tests it

DNSprobe compares the NS list from the parent with the NS records returned by your authoritative servers and highlights nameservers that exist only at the parent level.

Common issues

• Old providers still listed at the registrar after migration.
• Typo in the child zone causing different hostnames.
• Partial clean-up leaving ghost NS at the parent.

Best practices

• Remove obsolete nameservers from both parent and child zones.
• Verify NS sets after any registrar-side operation.
• Automate configuration where possible to reduce manual drift.

14. Domain CNAMEs

This check warns if the zone apex or other critical labels are configured as CNAME, which can cause interoperability issues.

Why this matters

Using CNAME at the zone apex conflicts with other record types like NS, SOA or MX and can break DNSSEC, email delivery or some DNS resolvers.

How DNSprobe tests it

DNSprobe inspects the zone for CNAME records at the apex and at other sensitive labels, then reports any configuration that could conflict with standards.

Common issues

• Zone apex configured as CNAME instead of A/AAAA.
• CNAME used together with other record types on the same label.
• CNAME chains that increase latency and failure risk.

Best practices

• Avoid CNAME at the zone apex; use ALIAS/ANAME where supported.
• Do not mix CNAME with other record types on the same name.
• Keep CNAME chains short and well-monitored.

15. NSs CNAME check

This check verifies that nameserver hostnames themselves are not CNAME records.

Why this matters

RFCs recommend that NS hostnames point directly to A/AAAA records. Using CNAME for NS can confuse resolvers, increase latency and break some DNS implementations.

How DNSprobe tests it

DNSprobe queries each NS hostname and verifies that it resolves directly to A/AAAA records without going through CNAME indirections.

Common issues

• NS records pointing to hostnames that are CNAMEs.
• Complex CNAME chains in front of nameservers.
• Use of CDN-style CNAMEs as NS hostnames.

Best practices

• Make NS hostnames point directly to A/AAAA records.
• Keep the addressing behind nameservers stable and predictable.
• Avoid hiding your NS behind multiple CNAME layers.

16. Different subnets

This check analyses whether your nameservers are spread across different network prefixes.

Why this matters

If all nameservers sit in the same subnet, a single routing issue, DDoS attack or maintenance event on that segment can take down all of them at once.

How DNSprobe tests it

DNSprobe groups nameserver IPs by subnet and flags cases where everything is concentrated in a single prefix.

Common issues

• All nameservers using the same /24 or /64 network.
• Secondary server configured but hosted in the same rack or VLAN.
• Anycast advertised from only one physical site.

Best practices

• Spread nameservers across different subnets and network segments.
• Consider multi-site or multi-provider hosting of DNS.
• Use anycast only when you can back it with multiple locations.

17. IPs of nameservers are public

This test confirms that nameserver IP addresses are publicly reachable and not part of private or reserved ranges.

Why this matters

Publishing private or unroutable IPs in NS records will make your domain unreachable from the Internet and may expose internal addressing schemes.

How DNSprobe tests it

DNSprobe checks each IP against known private, reserved and special-use ranges and warns if a nameserver address is not globally routable.

Common issues

• NS records pointing to RFC1918 or link-local IPs.
• Accidental publication of internal monitoring or management addresses.
• Misconfigured NAT leading to unreachable external IPs.

Best practices

• Use only globally routable IP addresses for public nameservers.
• Separate management interfaces from public DNS endpoints.
• Review NS IPs after network redesigns or provider changes.

18. DNS servers allow TCP connection

This check verifies whether your nameservers accept DNS over TCP in addition to UDP.

Why this matters

DNS over TCP is required for large responses, zone transfers and reliable DNSSEC validation. Blocking TCP can cause intermittent failures or validation errors.

How DNSprobe tests it

DNSprobe attempts to open TCP connections to each nameserver on port 53 and send test queries, recording whether the handshake and responses succeed.

Common issues

• Firewalls blocking TCP/53 while allowing UDP/53.
• Middleboxes or DDoS protection dropping TCP-based DNS traffic.
• Nameserver software misconfigured to listen on UDP only.

Best practices

• Ensure all authoritative servers listen on both UDP and TCP for DNS.
• Test TCP reachability from outside your own network.
• When enabling DNSSEC, verify that TCP works reliably from multiple ISPs.

19. Different autonomous systems

This test checks whether your nameservers are hosted in different autonomous systems (AS), not only different IPs.

Why this matters

Hosting all DNS servers within a single AS makes them vulnerable to routing incidents or peering problems affecting that provider. Spreading them across multiple AS increases resilience.

How DNSprobe tests it

DNSprobe looks up the ASN for each nameserver IP and groups them. It warns when all servers live in the same AS or in closely related networks.

Common issues

• All nameservers hosted by one ISP in a single AS.
• Redundant servers technically separate but behind the same transit provider.
• Anycast deployed only inside one provider backbone.

Best practices

• Host nameservers in at least two distinct autonomous systems.
• Combine on-premise DNS with a cloud or secondary DNS provider.
• Consider business continuity requirements when choosing DNS hosting.

20. Stealth NS records sent

This check analyses so-called "stealth" nameservers, which serve the zone but are not listed at the parent.

Why this matters

Stealth nameservers can be useful for hidden masters or internal monitoring, but if misused they create confusion and partial visibility of your DNS infrastructure.

How DNSprobe tests it

DNSprobe compares the list of servers actually answering authoritatively for your zone with the NS set visible at the parent and flags any extra hidden servers.

Common issues

• Production traffic unintentionally hitting stealth servers through custom resolvers.
• Hidden masters exposed to the Internet without proper hardening.
• Operators forgetting that stealth servers must also be kept in sync.

Best practices

• Use stealth nameservers deliberately, for clear operational reasons.
• Harden and monitor any hidden masters as carefully as public NS.
• Document the role of stealth servers to avoid surprises in incidents.

21. Test NS delegation manually from your own terminal

The NS section in DNSprobe compares what your own nameservers publish with what the parent zone and public resolvers see, including glue IPs, consistency of NS sets and basic reachability. You can reproduce most of these checks yourself from a terminal by querying NS records through your resolver, public resolvers and the TLD servers.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The examples below show how to see the NS records as returned by your current resolver, compare them with major public resolvers, then query a TLD server and finally check the A records (glue) for each nameserver:

                dig example.com NS +noall +answer
    
                # NS records for example.com as seen by your current recursive resolver    
                dig example.com NS @8.8.8.8 +noall +answer
                dig example.com NS @1.1.1.1 +noall +answer
    
                # Compare with major public resolvers (Google DNS, Cloudflare, etc.) to detect cache or visibility issues    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
    
                # Ask a TLD server directly to see the parent delegation and glue, then resolve each NS hostname to its IP address    
                dig ns1.example.com A +noall +answer
                dig ns2.example.com A +noall +answer
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to check which NS records are visible to your resolver, to public resolvers and to the TLD servers, and then resolve each nameserver to its IP address:

                dig example.com NS +noall +answer
    
                # NS records for example.com as seen by your current recursive resolver    
                dig example.com NS @8.8.8.8 +noall +answer
                dig example.com NS @1.1.1.1 +noall +answer
    
                # Compare with major public resolvers (Google DNS, Cloudflare, etc.) to detect cache or visibility issues    
                dig example.com NS @g.gtld-servers.net +norecurse +noall +authority +additional
    
                # Ask a TLD server directly to see the parent delegation and glue, then resolve each NS hostname to its IP address    
                dig ns1.example.com A +noall +answer
                dig ns2.example.com A +noall +answer
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query NS and A records through different resolvers. From a Command Prompt or PowerShell window, you can first see what your default resolver returns, then query public resolvers and a TLD server, and finally resolve each nameserver hostname to confirm its IP address:

                nslookup -type=NS example.com
    
                REM NS records for example.com as seen by your default resolver    
                nslookup -type=NS example.com 8.8.8.8
                nslookup -type=NS example.com 1.1.1.1
    
                REM Compare with major public resolvers (Google DNS, Cloudflare, etc.) by specifying the resolver IP    
                nslookup -type=NS example.com g.gtld-servers.net
    
                REM Ask a TLD server directly for the NS delegation, then resolve each NS hostname to verify its glue A record    
                nslookup -type=A ns1.example.com
                nslookup -type=A ns2.example.com
        

Important: only query DNS records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains or TLD servers without permission may be treated as abusive traffic by some providers.