DS · DNSKEY · RRSIG · AD
DNSSEC checker
Follow a domain’s chain of trust from the DS record at its parent to the keys and signatures in the zone, see which resolvers validate it, and get a verdict in plain English.
What gets checked
DNSSEC signs DNS answers so resolvers can detect forgeries. Trust flows down from the root: the parent zone (for example com) publishes a DS record that fingerprints the zone’s key-signing key, the zone publishes its DNSKEY set, and every answer carries an RRSIG signature.
- DS at the parent: key tag, algorithm and digest type of each DS record.
- DS ↔ DNSKEY match: the SHA-1, SHA-256 or SHA-384 digest of each key is computed in your browser and compared with the DS.
- Signatures: who signed the DNSKEY set and when the signatures expire.
- AD flag: whether Cloudflare, Google, dnsforge.de, DNS.SB and Control D validated the zone. A SERVFAIL that disappears when validation is switched off (CD bit) means the zone is bogus.
It does not re-verify the cryptographic signatures themselves; the AD flag from validating resolvers covers that. Entering a subdomain checks the zone it belongs to.
Frequently asked questions
What is the difference between DS and DNSKEY?
DNSKEY records hold the zone’s public keys and live in the zone itself. The DS record is a hash of the key-signing key, published by the parent zone through your registrar. The DS is what links your zone to the chain of trust.
Why can broken DNSSEC take a domain offline?
Validating resolvers refuse answers whose signatures do not check out and return SERVFAIL instead. A stale DS after moving DNS hosts, or expired signatures, makes the domain unreachable for everyone using those resolvers.
Does DNSSEC encrypt DNS?
No. DNSSEC proves answers are authentic but leaves them readable. Encryption between you and the resolver comes from DNS-over-HTTPS or DNS-over-TLS, which is how this site sends its queries.