DNS
DNS health report
See DNSSEC, CAA and the nameservers for one domain together, with the fixes in the order to do them.
Free, no accountLive check
Result
The verdict appears here once you press Run the report.
What this is
This dns health report runs the DNSSEC chain, CAA and nameserver checks for one domain together, and orders what it finds the way it actually needs fixing: a broken chain of trust and a locked-out certificate authority before the plainer notes about who serves the zone.
Three separate questions sit behind "is this domain's DNS healthy": does its signed chain of trust actually hold, which certificate authorities is it willing to let issue for it, and who is actually delegated to answer for it at all. None of the three tells the others apart - a domain can sign its records perfectly and still leave every CA free to issue, or lock issuance down to one CA while its own DNSSEC chain quietly does not match the key it published.
Checking the three apart means visiting three pages and holding the result of each in your head at once. This report runs all three against the one domain typed in, and reads the three results back as a single plain sentence before it gets into the detail underneath.
How to read the result
The table at the top gives DNSSEC, CAA and the nameservers one word each. "Fixes, in the order to do them" underneath turns every problem found into a numbered list: a broken DNSSEC chain or an issuance lockout comes before a plain note about how many nameservers were found, since the first two can actively break something and the third usually cannot.
Every finding keeps the detail its own check would give - the exact RFC section it cites, the record to change - with the check it came from named in front of it, so nothing here is thinner than visiting that check on its own would be.
Common mistakes
What goes wrong most often, and how to tell.
- Treating a clean DNSSEC chain as proof the rest of the domain is fine tooA domain can sign its own records correctly and still publish no CAA record at all, or run on a single nameserver with nothing backing it up. Each of these three is its own, separate risk, and a pass on one says nothing about either of the other two.
- Reading "no DNSSEC" and "no CAA" as the same kind of gapNeither is automatically a fault - most of the internet runs unsigned and with no CAA record at all - but they fail very differently when something does go wrong. An unsigned domain can be spoofed by a forged answer; one with no CAA record simply lets any public CA issue for it, which most domains have always allowed.
- Running this once after setup and never againA key rollover can leave a stale DS record behind, a CAA record can be added by one team and forgotten by another, and a nameserver migration can land half-finished. None of the three checks this report runs describe something that, once correct, stays correct forever.
Questions
What people ask about this tool.
- Because none of the three answers the others: a domain can have a perfectly signed DNSSEC chain and still allow any certificate authority to issue for it, or lock issuance down to one CA while running on a single nameserver with no second path if it goes down. Checking them together is the only way to see all three risks for one domain at a glance.
- Nothing less than its own page: it recomputes the same DS digest from the same DNSKEY bytes and shows the same per-resolver authenticated-data flag, never claiming to have verified a signature itself, since no DNS-over-HTTPS JSON API hands one back to check directly. This page just adds CAA and the nameservers alongside it in one pass.
- Not on its own. It means no restriction has ever been set, so any publicly trusted certificate authority remains free to issue for that name, which is the default most domains have always been in. It only becomes worth fixing if you specifically want to restrict issuance to a CA you actually use.
- Both: it reads the registry’s own RDAP nameserver list the same way the nameserver and DNS host checker does, and warns when that list no longer matches what the zone itself answers - the gap a nameserver change left half applied leaves behind. Matching a hostname to a likely host uses the same pattern list as that page too.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 4034: Resource Records for the DNS Security Extensions” read 13 October 2026
- IETF, “RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record” read 13 October 2026
- IETF, “RFC 9499: DNS Terminology” read 13 October 2026
- IETF, “RFC 2182: Selection and Operation of Secondary DNS Servers” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.