A DNS health audit checks the entire chain behind a domain at once - parent delegation, nameserver diversity, SOA timers, mail records, and security posture - rather than one record type in isolation.
Why a single record lookup is not a health check
Looking up one record type answers one question: does this record exist, and what does it say. A health audit answers a different question: does the whole delegation chain agree, and will it keep working under failure. Those are not the same thing. A domain can have a perfectly formed MX record and still lose mail if its nameservers are lame, its SOA serial is out of sync between servers, or its only two nameservers sit on the same /24 subnet behind the same upstream provider.
The chain runs from the parent zone down: the TLD servers hold NS records (and, ideally, glue records) pointing at the domain's own nameservers. Those nameservers must actually answer authoritatively for the zone - a nameserver listed in the delegation but not configured to serve the zone is "lame," and lame delegation is one of the most common causes of intermittent resolution failures that never show up in a single spot-check.
A full audit also cross-checks values that only make sense in relation to each other: the SOA REFRESH and RETRY intervals RFC 1035 defines for secondary-to-primary synchronization, whether every nameserver reports the same SOA serial number, and whether the nameservers themselves are spread across different networks and autonomous systems so that one outage does not take down the whole zone.
- Parent delegation - NS records at the TLD, glue records where the nameserver lives inside the domain itself
- Nameserver health - authoritative (not lame), publicly reachable, spread across different subnets and ASNs
- SOA consistency - REFRESH/RETRY/EXPIRE/MINIMUM within RFC-sane ranges, same serial across every nameserver
- Mail and security posture - MX reachability, SPF/DMARC presence and policy strength, DNSSEC chain status
Reading the audit results
Results are grouped into the categories the check actually runs: Parent, Nameservers (NS), SOA, MX, Security, and WWW. Each check reports pass, warning, fail, or info, and most include the raw detail behind the verdict - the nameserver hostnames, the SOA field values, the SPF record string - so a warning is never just a color, it comes with the record that produced it.
The Parent category confirms the domain is properly delegated: NS records exist at the parent, the TLD itself resolves, and the child's nameservers appear where the parent expects them. The Nameservers category goes further, individually testing each server: does it answer authoritatively, does it allow open recursion (a security risk, not just a hygiene issue), does it accept TCP connections (required for large or DNSSEC-signed responses), and are the servers diverse enough in network location that a single upstream failure will not take all of them offline at once.
The SOA category checks the one record most operators never look at directly. Its serial number should match across every nameserver - a mismatch usually means a zone transfer failed or is still in progress. Its REFRESH and RETRY values control how aggressively secondaries poll the primary, and values set far outside common practice (too low wastes bandwidth, too high delays propagation of legitimate changes) are flagged as warnings rather than failures, since RFC 1035 sets no hard bounds - only sane defaults.
MX, Security, and WWW round out the picture: whether mail servers resolve and are reachable, whether SPF and DMARC records exist and their policy strength (a DMARC record with p=none monitors but does not enforce, for instance), whether DNSSEC signing is present and complete, and whether the website's own A/CNAME chain is public and correctly configured.
| Category | What it verifies | Typical failure it catches |
|---|---|---|
| Parent | Delegation from the TLD is consistent and glue is present where needed | Parent NS list disagrees with what the domain itself serves |
| Nameservers | Each server is authoritative, reachable, non-recursive, network-diverse | A lame nameserver still listed as authoritative |
| SOA | Serial matches across servers; timers are within sane bounds | One secondary stuck on a stale serial after a failed transfer |
| MX / Security | Mail servers resolve; SPF/DMARC/DNSSEC are present and coherent | SPF record exists but has no enforcement mechanism |
What actually breaks a domain - and what just looks alarming
The failures worth acting on immediately are the ones with no fallback: a lame nameserver that the parent still delegates to, a missing NS-to-A chain that leaves a nameserver unreachable, or a SOA serial mismatch that means secondaries are serving stale data. These directly cause intermittent or total resolution failure for some fraction of queries, and the fraction grows as caches expire.
Several checks are best read as posture, not outages. Two nameservers instead of three is a warning about redundancy margin, not a sign anything is currently broken - RFC 2182 recommends multiple servers on separate networks for resilience but does not mandate a specific count. Likewise, all nameservers sharing one autonomous system is flagged even when that AS belongs to a large anycast network (several major DNS providers run exactly this way by design) - the check cannot always distinguish "one company, one legacy setup" from "one company, globally distributed anycast," so a single-ASN result deserves a second look at who actually operates it before treating it as risk.
DNSSEC status commonly comes back as "not detected" for domains that never opted in, which is informational, not a failure - DNSSEC adoption remains optional under RFC 4033 and its absence does not by itself indicate misconfiguration, only that the resolver cannot cryptographically validate the chain for that zone. A domain that has enabled DNSSEC and wants to see the actual DS/DNSKEY/RRSIG records and chain-of-trust status, rather than this audit's pass/fail summary, should use the dedicated DNSSEC checker.
FAQ
What does it mean for a nameserver to be "lame"?
A lame nameserver is one that appears in the domain's NS delegation but does not actually answer authoritatively for that zone - often because it was decommissioned or never fully configured. Queries sent to it fail or time out, and because resolvers rotate between listed nameservers, a lame server causes intermittent rather than constant failures, which makes it easy to miss without an audit that checks each server individually.
Why does the audit flag a domain for having only two nameservers?
RFC 2182 recommends multiple nameservers on separate networks so that one outage does not take the whole zone offline, but it sets no required minimum count. Two nameservers work and are common, but they leave less margin than three or more if one becomes unreachable during maintenance or an outage - the check reports this as a warning about redundancy, not as a failure.
All my nameservers show the same autonomous system - is that a problem?
It depends on who operates that AS. If a domain is on a small provider running all its nameservers from one data center under one AS, a single upstream failure can take every nameserver down at once. If the AS belongs to a large anycast DNS network, the same-AS result is expected and does not indicate a single point of failure, since anycast spreads the actual serving infrastructure across many physical locations under one network identity.
Why do the SOA serial numbers need to match across nameservers?
The SOA serial is how secondary nameservers know whether their copy of the zone is current. If one secondary reports an older serial than the others, it means a zone transfer failed or has not completed yet, and that server is answering queries with stale data - a new or changed record may not show up when a query happens to land on it.
The audit says DNSSEC is "not detected." Is my domain misconfigured?
Not necessarily. DNSSEC adoption is optional under RFC 4033, and a large share of domains never enable it. "Not detected" simply means no DNSKEY or DS records were found - it does not indicate an error unless DNSSEC was deliberately configured and only partially completed, which the audit reports differently (as a warning about partial keys or a missing DS record at the parent). For a domain that does have DNSSEC enabled, the dedicated DNSSEC checker breaks down the actual DS, DNSKEY, and RRSIG records and the chain-of-trust status in more depth than this summary.
Does a warning always mean something is currently broken?
No. Several checks report posture rather than active failure - nameserver count below the recommended margin, SOA timers outside common ranges, or a DMARC policy set to monitor-only rather than enforce. These describe risk or room for improvement, not a domain that is failing to resolve. Failures reserved for actual breakage - a lame nameserver, an unreachable MX host, a serial mismatch - are marked fail, not warning.
Related tools
- Pull the raw record set for any single type this audit summarizes, with full values
- Check nameserver records directly if the audit flags parent delegation or NS diversity
- Get a deeper read on DMARC policy strength than the audit's summary check
- Confirm whether a recent DNS change has finished propagating across resolvers worldwide
- See the actual DS/DNSKEY/RRSIG records and chain-of-trust status behind this audit's DNSSEC summary