🔏 DNSSEC Validator
Check whether DNSSEC (DNS Security Extensions) is enabled. We query Cloudflare DNS-over-HTTPS and inspect the AD (Authenticated Data) flag in the response, the DS record in the parent zone, and the DNSKEY records.
📖 What this check tells you
This check queries a validating resolver and confirms three things: the AD flag in the response (the marker that signature validation succeeded), the DS record published at the parent zone, and the zone DNSKEY itself. DNSSEC guarantees only that the answer you got was not tampered with; it encrypts nothing. Which domain you looked up still travels in the clear — that is what DoH and DoT are for.
| Item | What it means | How to fix it |
|---|---|---|
| DNSKEY present but no DS | The zone is signed, but the parent registry has not declared that this key can be trusted. The chain of trust is broken partway, so to a validating resolver the domain is simply unsigned — all the work of signing with none of the benefit. This most often appears right after a domain transfer. | Register the DS record (or the DNSKEY that generates it) in your registrar panel. It has four fields — key tag, algorithm, digest type and digest — which you can copy from your DNS provider. When transferring or changing nameservers, the safe sequence is remove the DS first, let the zone go unsigned, then re-add it afterwards. |
| DS exists but the AD flag is false | Validation is failing, almost always because an RRSIG expired or a key rollover went wrong. A DNSSEC failure surfaces as SERVFAIL rather than a missing domain, and for anyone on a validating resolver the site and the mail both disappear entirely. As misconfigurations go, this one is at the severe end. | Do not manage keys by hand. Use inline-signing yes; auto-dnssec maintain; on BIND, automatic KSK/ZSK rollover on Knot, or the one-click toggle if your authoritative DNS is a managed service. Signature lifetimes default to roughly two to four weeks, so once re-signing stops you have only weeks before everything breaks — put monitoring on it. |
| Some lookups break right after enabling | Signatures make responses larger. When a UDP packet fragments and gets dropped by a middlebox, or the fallback to TCP is blocked by a firewall, the answer simply never arrives — a failure mode that is hard to read. Lopsided symptoms such as the website working while mail does not can trace back to this. | Set the EDNS0 buffer size to 1232 bytes — the DNS Flag Day 2020 recommendation — and make sure TCP/53 is open on your firewall. Choosing ECDSA P-256 (algorithm 13) over RSA keeps both keys and signatures small, which largely prevents the problem in the first place. |
DNSSEC protects DNS answers and nothing else — it sits in a different layer from website security. You still need HTTPS with it enabled, and conversely HTTPS already stops a spoofed DNS answer at certificate validation. What still makes DNSSEC worthwhile is that certificate issuance itself runs over DNS — the ACME DNS-01 challenge and the CAA lookup — so an attacker who can forge DNS can obtain a genuine certificate.