Validate a domain's DNSSEC chain of trust — DS, DNSKEY, and why it failed if it did.
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, so a resolver can prove that the answer it received hasn't been tampered with in transit — protecting against cache poisoning and man-in-the-middle DNS spoofing.
It does not encrypt DNS traffic (that's a separate concern, handled by DoH/DoT) — it only authenticates it.
Each zone signs its own records with a private key (DNSKEY). A hash of that key — the DS record — is published in the parent zone, signed by the parent's own key. This chain continues up to the root zone, which is trusted by every validating resolver out of the box.
This tool asks Google's public resolver (dns.google, DNSSEC-aware) to look up the domain and reports its own AD (Authenticated Data) flag — the same signal your ISP's or browser's resolver relies on.
DS — published in the parent zone; its presence is what makes a domain "signed" at all.
DNSKEY — the zone's own public keys: a Key Signing Key (KSK, flag 257) and usually a Zone Signing Key (ZSK, flag 256).
RRSIG — the actual signature attached to each signed record set, included inline when a lookup is made with the DNSSEC OK bit set.
No DS record exists at the parent zone. This is the default for most domains — DNSSEC is opt-in, not a failure by itself.
A DS record exists, but the signature doesn't check out — usually a stale DS left after rotating DNSKEYs, an expired RRSIG, or a registrar/DNS-host misconfiguration. Browsers and resolvers that enforce DNSSEC will refuse to resolve the domain at all until this is fixed.
RRSIG records carry validity windows. If a zone stops re-signing (e.g. an automation job breaks), everything downstream starts failing validation once the signatures expire — a common self-inflicted outage.