Why the delegation matters more than the records
When a resolver looks up your domain it does not start at your DNS provider. It starts at the parent zone (com, co.uk, …), which hands it a list of your nameservers and, when those nameservers live inside your own domain, their addresses (glue). If that list is wrong, stale, or points at servers that do not consider themselves authoritative, some resolvers will fail or serve old data no matter how perfect the records at your provider are. That is why this report runs before anything else in the domain checkup.
What each check means
| Check | What we do | When it fails |
|---|---|---|
| Parent / child agreement | Compare the NS set the parent hands out with the NS set each of your nameservers publishes. | A nameserver is listed on one side only — usually a provider change where the registrar or the zone was updated, but not both. |
| Glue | For nameservers inside your own domain (ns1.example.com for example.com), confirm the parent supplies their addresses and that those addresses match the zone. | Missing glue makes the delegation circular; stale glue sends resolvers to an old server. |
| Lame delegation | Ask every listed nameserver for your SOA with recursion disabled and require the AA (authoritative answer) flag. | A server that is listed but not configured for the zone. Resolvers that pick it get SERVFAIL or REFUSED. |
| SOA serial agreement | Read the SOA serial from each authoritative server. | Serials differ — a secondary has not transferred the latest zone, or two providers are being run without sync. |
| Reachability | UDP and TCP to each nameserver, with response times. | Unreachable servers slow every lookup; UDP-only servers break large answers and zone transfers. |
| Diversity | Count nameservers, compare their networks (/24, /48) and announcing ASNs. | One network or one provider is a single point of failure — RFC 2182 asks for at least two, on separate networks. |
| CNAME sanity | Follow CNAME chains for the apex and www; look for loops, long chains, and a CNAME at the apex. | A CNAME at the zone apex is invalid next to SOA/NS; loops never resolve. |
| DNSSEC chain | Read DS from the parent and DNSKEY from the child, match key tags, and ask a validating resolver. | A DS that matches no DNSKEY makes validating resolvers (Google, Cloudflare, Quad9, most ISPs) return SERVFAIL — the domain is down for a large share of users. |
| TTLs | Inspect the TTLs on NS, SOA, and apex records. | Extremely low TTLs multiply query load; very long ones make every change slow; a huge SOA minimum keeps “does not exist” cached for hours. |
Read the full explanation of dns health report results ↓Show less ↑
Reading the nameserver table
Each row is one nameserver as it actually answered. Addresses are what the zone publishes for that name; Glue is what the parent hands out. Authoritative is the AA flag on that server's own SOA answer — a "no" there is a lame server even if it returns records. Serial should be identical across the row; Network shows the announcing AS so you can see whether all your servers share one provider.
Checking it yourself
# Who does the parent say your nameservers are? (replace com with your TLD)
dig @a.gtld-servers.net example.com NS +norecurse +noall +authority +additional
# Does each nameserver consider itself authoritative, and what serial does it hold?
for ns in $(dig +short NS example.com); do
echo "$ns: $(dig @$ns example.com SOA +norecurse +noall +answer +comments | grep -E 'flags|SOA')"
done
# DS at the parent vs DNSKEY in the zone
dig example.com DS +short
dig example.com DNSKEY +short