Inputs
Example
example.com -> DS at parent, DNSKEY at child, RRSIG evidence, and secure/bogus resolver status.
DNSSEC Validator
Review DS, DNSKEY, RRSIG structural inventory and the validating resolver's DNSSEC verdict for a domain.
Use it to review DNSSEC evidence without confusing record presence with proven resolver validation.
What a DNSSEC chain actually consists of
DNSSEC failures have a signature symptom: the domain works for some users and is dead for others. Validating resolvers answer SERVFAIL for a broken chain while non-validating resolvers happily serve the records, so the outage follows resolver choice rather than geography or network. Whoever is on Quad9 sees an outage; whoever is on a legacy ISP resolver sees nothing wrong. These partial outages are confusing precisely because the zone data itself is fine.
Behind every such incident is a chain with one broken link. The parent zone publishes a DS record — a digest of the child's key-signing key. The child publishes its DNSKEY set and signs its record sets with RRSIGs. Validation walks from the trust anchor through each delegation, and every link must hold: DS must match a live DNSKEY, signatures must be current, algorithms must line up. This tool fetches that evidence for a domain — DS, DNSKEY, RRSIG, and the resolver's own verdict — and shows where the story stops adding up.
Debugging from symptom to broken link
Start from the resolver status, because it defines the class of problem. Secure means the chain validates end to end. Insecure means no DS exists at the parent — the zone is simply unsigned, which is a policy state rather than an error. Bogus is the acute case: signed, but broken, and validating resolvers will refuse to answer. Only bogus takes the domain down, and that distinction decides whether you are firefighting or planning.
For a bogus result, check the two classic culprits in order. First signature freshness: RRSIGs carry explicit expiry timestamps, and an expired signature almost always means the re-signing automation died some days ago — the outage begins when the last signature lapses, not when the tooling broke. Second, the DS-to-DNSKEY match: after a key rollover, a DS at the parent still digesting the retired key breaks everything, which is why the old key must remain published until the parent's update has propagated past its TTL.
What a browser view can and cannot validate
Pasted records stay local, and live queries run only on request, using browser DNS-over-HTTPS with a same-origin fallback. The page presents the named resolver's validation verdict and structural chain inventory; it does not itself recompute every signature, and it displays NSEC and NSEC3 material as context without re-deriving full denial-of-existence proofs. Bare SERVFAIL, timeout, or generic failure is unavailable evidence, not proof of bogus; explicit resolver verdict or DNSSEC-specific EDE evidence is required for that classification. For an authoritative offline verdict, a local validating resolver remains the reference.
Frequently asked questions
Users on some networks reach the domain, others get errors. DNSSEC?
That pattern can be consistent with DNSSEC validation failure, but it is not proof. Bare SERVFAIL remains unavailable because many other failures produce it. Require an explicit bogus resolver verdict or DNSSEC-specific EDE evidence before classifying the chain as bogus.
What is the difference between insecure and bogus?
Insecure means the parent has no DS record: the zone is unsigned and resolvers do not expect signatures. Bogus means the zone claims to be signed but validation fails. Insecure is a choice; bogus is an outage.
How do RRSIG expiry times cause outages?
Signatures are only valid within their inception and expiration window. Zones re-sign automatically, and when that automation fails, nothing visible happens until the first signature expires — then validating resolvers drop the zone. Monitoring RRSIG expiry is monitoring your signing pipeline.
Why did my domain break after a key change?
Most likely the DS at the parent still matches the old key, or the old DNSKEY was withdrawn before the parent update propagated. Rollovers must keep both keys live through the overlap window; skipping that step turns a routine rotation into a bogus zone.
Do KSK and ZSK matter for reading the output?
Yes. The DS at the parent corresponds to the key-signing key, which in turn signs the zone-signing key that signs ordinary records. When the DS matches no visible DNSKEY, compare it against the KSK specifically — that is the link the parent anchors.
Is a shown algorithm number a security assessment?
No, it is inventory. It helps spot deprecated algorithms and mismatches between DS and DNSKEY, but the display does not prove the cryptography was independently verified by this page.