DNSSEC Checker
Query a domain's DNSKEY record against multiple public DNS resolvers (Google, Cloudflare, and more) to check whether its DNSSEC signature chain validates correctly.
Tips
- The AD (Authenticated Data) flag is only set when the DNS resolver you queried performed DNSSEC validation itself. Resolvers that don't support DNSSEC can't give a meaningful result.
- "DNSSEC not enabled" is not an error — most domains still don't use DNSSEC, and it has no direct effect on search ranking or email deliverability.
- If validation fails, first check whether the key tag and digest in the DS record registered at your registrar match your current DNSKEY.
- DNSSEC signatures (RRSIG) have an expiration date. Confirm that your DNS software's automatic re-signing hasn't stopped.
- Right after enabling DNSSEC, validation may briefly show as "failed" until the DS record propagates to the parent zone.
Frequently Asked Questions
Side Note — Why DNS needed a way to stop spoofing
When DNS was designed in 1983, it had no cryptographic way to confirm who actually sent a response. A resolver trusted any UDP packet that arrived with a plausible-looking transaction ID — a protocol built on good faith, vulnerable to source-IP spoofing and ID guessing. In 2008, security researcher Dan Kaminsky showed the industry that this weakness could be exploited to perform practical, fast cache poisoning attacks (injecting forged records into a resolver's cache), a discovery that sent shockwaves through the DNS community.
DNSSEC (DNS Security Extensions) is the standardized answer to that problem. It uses public-key cryptography to prove that a response was signed by the zone's legitimate operator. A domain signs its records with its DNSKEY, and a DS record registered in the parent zone attests to that key's digest — building an unbroken chain of trust from the DNS root down to the individual domain.
The AD (Authenticated Data) flag in a DoH (DNS over HTTPS) response is the result of the resolver performing that DNSSEC validation on your behalf. Applications don't need to implement signature verification themselves — querying a trusted resolver and seeing AD=true is an indirect assurance that the response wasn't tampered with, provided the transport between the resolver and the app (HTTPS) is separately secured.