Three bits in DNS messages carry DNSSEC state:
- DO
- DNSSEC OK, set by the asker: "send me the DNSSEC records too" (RFC 3225).
- AD
- Authenticated Data, set by a validating resolver in its answer: "I checked the whole chain of trust and it is good" (RFC 4035, RFC 6840).
- CD
- Checking Disabled, set by the asker: "do not validate, give me the data anyway". Useful for debugging.
How our checker uses it
We ask Cloudflare's validating resolver (1.1.1.1) with DO set and CD clear. If it sets AD on the answer, the domain is Signed & validating. If the zone has DNSKEY records but no AD, it is Signed, not validating: usually no DS at the registrar. No DNSKEY at all is No DNSSEC.
Test it yourself
dig +dnssec dnssec.in A @1.1.1.1 ;; flags: qr rd ra ad; ← "ad" = validated dig +dnssec +cd broken.example A @1.1.1.1 # answer comes back even if validation fails delv dnssec.in A # BIND's validating lookup tool ; fully validated
Who trusts the AD flag?
Your laptop's stub resolver usually does not validate. It trusts the AD flag from the recursive resolver, so the path between them must be trusted too (a local resolver, or DNS over HTTPS or TLS). When validation fails, the resolver does not send a wrong answer with AD clear: it sends SERVFAIL. See troubleshooting.