Expert Tools

DNSSEC adds cryptographic signatures to DNS responses, so a resolver can verify that what it received actually came from the zone's owner and wasn't altered in transit. Without it, DNS is trivially spoofable on an unsecured network path - and every protocol on this site that relies on DNS for anything security-relevant (DANE most directly, but in principle any of them) is only as trustworthy as the DNS carrying it.

Two pieces have to agree

A DS record, published at your registrar, points at a DNSKEY published in your own zone via a cryptographic digest. Both existing isn't enough on its own - the digest actually has to match. A DS record left over from a key that was since rotated is a real, observed failure mode: it looks configured at a glance, but a validating resolver treats it exactly like a broken chain. This check recomputes the digest from your published DNSKEY(s) and compares it directly, rather than only checking that both records exist.

Five verdicts, not two

"DNSSEC is on" or "off" hides several genuinely different states. NOT SIGNED: no DNSSEC anywhere in this name's ancestry. INCOMPLETE: DNSKEY published, but no DS submitted to the registrar yet - normal mid-rollout, not yet trusted by validating resolvers. BOGUS: a chain that should validate but doesn't, at whichever specific link the findings below identify. UNVERIFIABLE: blocked by a real limitation of this check (see below) rather than by anything actually wrong. SECURE: the complete chain, root to this domain's own signed SOA record, verifies.

A subdomain is checked against its real zone

www.example.com usually has no DNSKEY of its own - not because DNSSEC is missing, but because it's an ordinary name inside the example.com zone, which is what's actually signed. This check finds that zone (walking up from the name given until it finds one that actually publishes DNSKEY records) and checks against it, rather than reporting "not configured" for a name that was never going to be a signed zone on its own.

Since 13 September: the actual chain, not just one link

Confirming a DS digest matches a published DNSKEY proves one link is intact - it says nothing about whether the parent zone's own signature over that DS record is genuine, or whether the parent's own key is trusted by anything, or whether the domain's own records are actually signed rather than merely accompanied by a key. This check verifies the real thing at every step: RFC 4034/4035 signature checks (including the structural checks a cryptographic signature never actually covers by itself - the RRSIG's claimed owner, signer and label count) from this domain's own SOA record, up through each parent zone, to one of the root zone's own IANA-published trust anchors (iana.org/dnssec/files) rather than assuming it. This is the same validation a full DNSSEC-validating resolver performs before trusting a signed answer at all - done here explicitly, once, rather than taken on faith from whichever resolver happens to answer a query.

What this still doesn't cover

Algorithm 16 (Ed448) can't be verified here: PHP's sodium extension, the only non-OpenSSL signing primitive available without pulling in a third-party library, implements Ed25519 but not Ed448, and this project writes no cryptography of its own. In practice this covers a vanishingly small number of zones - the root, every major TLD, and the large majority of signed domains all use RSA or ECDSA - but a domain that does use it will show as UNVERIFIABLE rather than silently skipped or wrongly marked broken. Beyond that: this checks signatures and the chain of trust, not whether a resolver on some other network path would actually receive these same, unmodified records - that's a statement about this one query, from this one server, same as every other live check on this site.