DNSSEC Validator

What is DNSSEC?

DNS Security Extensions add cryptographic signatures to DNS records so that resolvers can verify the answer they received hasn't been tampered with on the wire. Without DNSSEC, a man-in-the-middle (a hostile café Wi-Fi, a compromised resolver, a state-level attacker) can spoof responses — point your bank's hostname at their phishing server, return a different MX so your email goes to them. DNSSEC makes that detectable: forged responses fail signature verification and a validating resolver discards them.

It's important to be clear about what DNSSEC doesn't do: it doesn't encrypt anything. The bytes on the wire are still plaintext DNS. That's what DoH and DoT solve. The two are complementary — DNSSEC authenticates the data; DoH/DoT hides it.

The chain of trust

DNSSEC works like a trust chain rooted at the DNS root zone (.). Each zone signs the delegation to its children using a DS record, which is a hash of the child's signing key. The chain looks like this:

• The root zone publishes a DNSKEY for itself. The hash of that key — the trust anchor — is hardcoded into every validating resolver.
• The root zone's NS delegation for .com is accompanied by a DS record pointing at .com's KSK.
• .com's zone publishes a DS for example.com pointing at example.com's KSK.
• example.com publishes its DNSKEY records (KSK + ZSK) and RRSIG signatures over its own records.

A validating resolver walks the chain from root to leaf: it has the root trust anchor, so it can verify the root's signatures over the DS for .com, which lets it verify .com's signatures over the DS for example.com, which lets it verify example.com's keys, which signed the answer you actually asked for. Any link missing or broken → the resolver returns SERVFAIL.

KSK and ZSK

Two key types, by convention. The Key Signing Key (KSK, flags = 257) is the long-lived key whose hash sits in the parent's DS record. It signs the DNSKEY set itself — so any change to the keys for the zone is signed by the KSK. The Zone Signing Key (ZSK, flags = 256) is the workhorse: it signs the actual records (A, MX, TXT, etc.) and is rotated more frequently because it sees more use. Splitting the roles keeps the high-stakes operation (changing what the parent points at) separate from the routine one (rotating the in-zone signing key).

Why isn't DNSSEC universal?

Three reasons it stalled around ~30% adoption:

• Operational risk. A misconfigured DNSSEC zone is worse than no DNSSEC — validating resolvers will refuse to answer for the domain at all. People remember the outages.
• Registrar support. To enable DNSSEC, the DS record has to be uploaded to the registrar via a DNS-record-publishing UI that many small registrars never built well, or at all.
• Operational overhead. Keys need rotating, the DS at the parent needs updating in lockstep, and an expired signature or a stale DS breaks the zone. Hosted DNS providers (Cloudflare, Route 53, etc.) automate all of this if you let them; self-managed BIND zones are the high-skill operation.

Notes on this tool

• We use Cloudflare's DoH with the DO bit set (?do=1) so the response includes DNSSEC records. The AD flag on the response tells us whether Cloudflare's resolver successfully validated.
• Key tag matching is computed locally per RFC 4034 Appendix B — we hash each DNSKEY's RDATA and compare against the DS records' key-tag field. This catches "DS points at a rotated-out key" misconfigurations.
• RRSIG expiry is computed against the current time. The 7-day-warning threshold is conservative; real-world zones re-sign every few hours.
• For a full DNS-records picture (not just DNSSEC), the DNS lookup shows every record type. For the related cert-side story, the CAA lookup and CT search cover certificate authorisation.