Skip to content
IPeek

DNS Health Check

A full delegation & DNS report card

Checking…

What is a DNS health check?

A DNS health check inspects how a domain is delegated and configured end to end, not just one record type. It asks the parent (TLD) servers what they publish for your domain, then asks your own nameservers directly, and compares the two. Mismatches between the parent and your servers — missing glue, disagreeing NS lists, out-of-sync SOA serials, lame or open-recursion nameservers — are exactly the problems that cause slow, intermittent or silently broken DNS. IPeek runs every check and tells you, in plain English, why each one matters and how to fix it.

Parent delegation, glue and the chain that finds your domain

Every lookup for your domain starts at the parent zone — the TLD registry (for example .es or .com) — which holds the NS records that point resolvers to your nameservers. If those nameservers live inside your own domain, the parent must also publish their IP addresses as "glue", otherwise resolvers face a chicken-and-egg loop. A healthy delegation has the parent and your own servers agreeing on the same NS set, with glue present where needed. When they disagree, some resolvers follow stale information and your changes appear to work for some users but not others.

Nameserver health: redundancy, authority and recursion

RFC 2182 recommends multiple nameservers on different networks so a single outage never takes your domain offline. Each one must answer authoritatively for your zone — a "lame" server that does not is a silent reliability hole. Your authoritative servers should also refuse recursion for strangers: an open recursive nameserver can be abused for cache poisoning and DDoS amplification. IPeek queries each of your nameservers directly to confirm they respond, answer authoritatively, agree with each other, support TCP, and keep recursion closed.

SOA, MX and apex sanity

The SOA record carries your zone's serial number and timing values; every nameserver must report the same serial, or your zone is out of sync and changes propagate unevenly. The serial should follow the YYYYMMDDnn convention, and the refresh/retry/expire/minimum timers should sit in the RFC-recommended ranges. On the mail side, MX records must be hostnames (never bare IPs or CNAMEs) that resolve to public addresses. Finally, the apex (your bare domain) should publish an address but not a CNAME, which RFC 1912 forbids alongside other records.

Frequently asked questions

How is this different from a normal DNS lookup?

A DNS lookup shows you the records as seen through a recursive resolver. A health check goes further: it queries the parent TLD servers and each of your own nameservers directly, then compares them. That lets it catch delegation problems a plain lookup hides — missing glue, parent/child NS mismatches, lame or disagreeing nameservers, and out-of-sync SOA serials.

What is glue and why does a missing glue record matter?

Glue is the IP address of a nameserver, published by the parent zone alongside the NS record. It is required when your nameservers are inside the same domain they serve (for example ns1.example.com serving example.com), because resolvers would otherwise need to resolve the nameserver before they can resolve anything. Missing glue in that case breaks resolution; if your nameservers are on a different domain, glue is optional and only saves one extra lookup.

Why should my nameservers not allow recursion?

Authoritative nameservers should answer only for the zones they host. A nameserver that performs recursion for anyone (an "open resolver") can be abused for DNS amplification DDoS attacks and is more exposed to cache poisoning. If the health check flags open recursion, disable recursion on the authoritative server or separate your authoritative and recursive roles onto different hosts.

What does it mean if my nameservers disagree on the SOA serial?

The SOA serial is a version number for your zone. When your nameservers report different serials, at least one is serving stale data — usually a secondary that failed to transfer the latest zone from the primary. The result is inconsistent answers depending on which server a resolver happens to hit. Check zone transfers (AXFR/IXFR), the primary's notify settings, and the SOA refresh timer.

Is a single MX record or two nameservers a problem?

Neither is an error, but both are single points of failure. With one MX, mail can be lost if that server is down long enough; a backup MX adds resilience. Two nameservers is acceptable per RFC 2182, but three or more on different networks is safer. The health check flags these as warnings, not failures — they are worth improving, not emergencies.