DNSSEC check
Checks whether the zone is signed and whether the chain of trust validates up to the root. Half-finished DNSSEC is worse than none: strict resolvers refuse the domain altogether.
Need another tool?
Pick one of the 25 belowOutput
What the DNSSEC check measures
A DNSSEC check reads three things from Cloudflare's 1.1.1.1 with the DNSSEC bit set: the DS records, which the parent publishes as the fingerprint of the child's key; the DNSKEY records, the public keys the zone publishes; and an A query, to see whether the resolver set the AD flag, meaning it validated the chain up to the root. The check asks about a zone, not an address.
The zone is reported as signed when both a DS at the parent and a DNSKEY in the zone were found. The signatures themselves are not verified here; the page says Validated by the resolver because that is what was measured. If the DS or DNSKEY query went unanswered the status is unknown rather than no DNSSEC, since that claim would otherwise rest on a timeout.
How to read the result
The banner says signed, no DNSSEC, broken (a DS at the parent with no DNSKEY in the zone, or a chain that does not validate), or unknown; a broken chain is seen by asking again with checking disabled, since a validating resolver answers every question about such a zone with SERVFAIL; the rows give Signed, Validated by the resolver and the resolver asked. The DS table lists key tag, algorithm, digest type and the digest itself, the value to compare character by character with what your registrar has published. The Keys table lists each DNSKEY with its flags (257 a key-signing key, 256 a zone-signing key), algorithm and size. For a subdomain, DS and DNSKEY are read at the apex of the zone it lives in and that zone's state is reported, because DNSSEC belongs to a zone, not to each name in it.
Half-done DNSSEC is worse than none. A DS at the parent with no matching DNSKEY, a DS left behind after a move to a provider that does not sign, or a key rolled without updating the DS all break the chain, and validating resolvers then refuse the whole domain with SERVFAIL, for every record, for everyone. Here the banner says the chain is broken and why: a populated DS table beside an empty Keys table, or both tables filled for a chain the resolver refuses to validate. No DNSSEC at all is not an error; it is simply unsigned.
When it is useful
A domain has stopped resolving on some networks and works on others. Networks with validating resolvers fail a broken chain and the rest never notice, exactly the pattern a stale DS produces. If the DS does not match the keys, remove or correct it at the registrar.
Before and after changing DNS hosting on a signed zone: the DS has to be removed before the move and republished for the new provider's keys afterwards, and this check confirms each step. WHOIS shows whether the registry records the delegation as signed; the Full report includes the same section among the rest.
Common questions
What does DNSSEC do?
It signs DNS records so a validating resolver can tell a genuine answer from a forged one, through a chain of keys from the root to the zone. It does not encrypt or hide anything; it proves the answer is what the zone published.
Is it a problem that my domain has no DNSSEC?
No. An unsigned zone resolves everywhere. The fault to avoid is a broken chain, which makes validating resolvers refuse the whole domain. Sign only when your provider supports it and you can keep the DS at the registrar in step.
Why does my signed domain fail on some networks?
The DS at the parent does not match the keys in the zone, usually after a provider change or key rollover. Resolvers that validate return SERVFAIL; those that do not carry on. Compare the digest here with your provider's key material.
Does this tool verify the signatures itself?
No. It reports whether 1.1.1.1 validated the chain, which is what the AD flag means, and shows the DS and DNSKEY records so you can compare them.
Limits. The DNS, WHOIS and SSL tools allow up to 20 requests a minute per IP address. Ping, traceroute and MTR send real packets to their target, so they allow 6 a minute.
The port check runs only against your own IP address. That is deliberate: the question people actually have, "is this port reachable from outside?", is answered by it, while this server cannot be used to scan anyone else's network.
Private and reserved addresses. These are refused by the tools that really connect to their target: the SSL check, ping, traceroute, MTR and the port check. The DNS tools have no such limit, because they only ask a nameserver a question and never connect to the address itself.