DNS
DNSSEC chain checker
See whether a domain publishes a DS record that actually matches its own DNSKEY, recomputed by hand rather than taken on trust.
Free, no accountLive check
Result
The verdict appears here once you press Check the DNSSEC chain.
What this is
This dnssec chain checker fetches a domain's DS record and its DNSKEY separately, then recomputes the digest itself - flags, protocol, algorithm and key bytes hashed the way RFC 4034 defines - so a published DS record that does not actually match its own key is caught rather than assumed correct because a record exists at all.
DNSSEC adds two record types to an ordinary delegation: a DNSKEY, published by the zone itself, and a DS record, published one level up at the parent, which names the key tag, algorithm and a hash of that exact DNSKEY (RFC 4034 §5). A resolver that trusts the parent can therefore trust that this specific key, and no other, speaks for the child zone - but only if the DS record's digest genuinely is a hash of the key that is actually published, which nothing stops from drifting apart after a rollover goes wrong.
This page treats "a DS record exists" and "the DS record matches the DNSKEY" as two separate facts, because they are: a stale DS record left over from a key rollover, or one copied from the wrong zone, publishes successfully and looks identical to a correct one until something actually hashes the current key and compares it.
How to read the result
The table of DS records shows each one's key tag, algorithm and digest type, and a plain result of whether this tool's own hash of the matching DNSKEY produced that same digest. A digest type outside SHA-1 and SHA-256 is reported as unverifiable rather than guessed at, since this page only implements the two most common ones.
The authenticated-data flag each resolver returns is shown on its own, never merged into the digest result above it: that flag is the resolver's claim to have checked an RRSIG signature, which is math this tool has no way to redo itself over a JSON DNS API. Two resolvers agreeing is the strongest second signal this page can offer - not proof the signature is valid, only that two independent validators currently say so.
Common mistakes
What goes wrong most often, and how to tell.
- Treating "a DS record exists" as the same as "DNSSEC works here"A DS record publishing successfully only proves the parent zone accepted a hash; it proves nothing about whether that hash still matches the key the child zone actually serves today, which a rollover gone wrong breaks silently.
- Reading one resolver's authenticated-data flag as a universal verdictThe AD flag belongs to the one resolver that set it, built from whatever trust anchors and cached state that resolver currently holds. A different resolver can disagree at the exact same moment, which is a real, checkable discrepancy rather than a fluke to ignore.
- Assuming a missing DS record means the zone is simply unsignedA DNSKEY with no DS record above it is a specific, named failure mode - RFC 4035 §2 calls it an insecure delegation - not the same plain unsigned state as a zone with neither record at all. The key is published and ready; nothing above it has been told to trust it yet.
Questions
What people ask about this tool.
- No. Neither Cloudflare's nor Google's DNS-over-HTTPS JSON API hands back an RRSIG for this tool to check the math on itself, so instead it recomputes the one piece of the chain it can - the DS digest over the DNSKEY's own bytes - and shows each resolver's own authenticated-data flag as a separate, named signal rather than folding the two together into a false claim of having verified a signature.
- It means the hash the parent zone publishes for this domain's key does not correspond to any key this domain actually serves right now, which a validating resolver treats as a broken chain rather than a minor mismatch. The most common cause is a key rollover where the new DNSKEY was published before the matching DS record replaced the old one, or where the DS record was generated from the wrong key entirely.
- Each resolver validates independently against its own cached copy of the chain, so a key rollover caught mid-flight, a brief outage reaching one resolver's own trust anchor, or simple timing between two caches can leave one resolver still trusting an answer the other has already stopped trusting. Neither answer is wrong by itself; the disagreement itself is the useful fact.
- It is not the same. An insecure delegation is a zone that has done the work of publishing a DNSKEY and signing its own records, but whose parent zone has not yet been told, through a DS record, to trust that key - so a validating resolver still treats every answer from that zone as unauthenticated even though the signing machinery is fully in place and only the registrar step remains.
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 4035: Protocol Modifications for the DNS Security Extensions” 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.