DNSSEC: chain of trust and validation failure

Your DNS record looks correct in every authoritative tool. But 30% of users cannot reach your site — they see DNS_PROBE_FINISHED_NXDOMAIN. The other 70% are fine. The difference is not which ISP they use; it is whether their resolver validates DNSSEC. You rolled a KSK last week and forgot to update the DS record at the parent registrar. The chain snapped.

What DNSSEC does and does not do

DNSSEC authenticates DNS responses: it proves that the A record for bank.example came from the legitimate authoritative server and was not forged in transit. It does not encrypt DNS messages — an eavesdropper can still see which domain you queried; that is what DoH and DoT address. DNSSEC validates data; encryption hides queries.

Key roles: ZSK and KSK

Every signed zone publishes two types of keys:

• ZSK (Zone Signing Key) — signs the actual data RRsets (A, MX, TXT records, etc.). Rotated frequently (every 1–3 months in practice).
• KSK (Key Signing Key) — signs only the DNSKEY RRset that publishes the ZSK. Rotated rarely (every 1–3 years). Its hash is published in the parent zone as a DS (Delegation Signer) record.

The split exists so ZSK rotation is cheap (no parent update needed), while KSK rotation — which requires parent coordination — is rare.

The chain of trust

Every validating resolver carries one hardcoded trust anchor: the fingerprint of the root zone’s KSK. Validation walks downward:

1. Resolver holds root KSK fingerprint as trust anchor.
2. Root publishes DNSKEY (root KSK + root ZSK). Resolver verifies root KSK matches the trust anchor.
3. Root ZSK signs the .com DS record. Resolver verifies the .com DS with root ZSK.
4. .com publishes DNSKEY (.com KSK + ZSK). Resolver verifies .com KSK matches the DS hash from step 3.
5. .com ZSK signs the example.com DS record. And so on, down to the leaf zone.
6. Leaf zone’s ZSK signs the A record. RRSIG travels with the answer.
7. If every step verifies → mark answer AD (Authentic Data). If any step fails → mark BOGUS → return SERVFAIL.

The KSK rollover failure mode

The most common DNSSEC incident:

1. Operator generates a new KSK in the child zone.
2. Operator updates DNSKEY at the child — new KSK now signs the DNSKEY RRset.
3. Operator forgets to update the DS record at the parent registrar.
4. Result: parent’s DS hashes the old KSK; child’s RRSIG is produced by the new KSK.
5. Validating resolvers fetch the child DNSKEY, verify RRSIG — it validates with the new KSK — but then check DS at parent and find the hash does not match. Chain broken → BOGUS → SERVFAIL.

Only resolvers that validate DNSSEC (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9) return SERVFAIL. Non-validating ISP resolvers serve the unsigned answer normally. This splits traffic: roughly 30–40% of global users (those on validating resolvers) cannot reach the site; the rest can.

$ dig @1.1.1.1 +dnssec api.bank.example
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0

$ dig @8.8.8.8 +dnssec api.bank.example
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8821

$ dig @1.1.1.1 +cd api.bank.example     # +cd = checking disabled
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1284
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1
api.bank.example.   60   IN   A   203.0.113.42

NSEC vs NSEC3: denial of existence

DNSSEC must also prove that a name does not exist — otherwise an attacker could delete a record and claim “there is no A record for bank.example.” The mechanism:

• NSEC: chains zone names alphabetically. “Between alpha.example.com and zebra.example.com nothing exists.” Easy to verify but lets an attacker walk every NSEC record to enumerate the entire zone.
• NSEC3 (RFC 5155): hashes names with a salt before chaining. Adjacent entries in the chain are hash-adjacent, not alphabetically adjacent. Prevents trivial zone enumeration; a rainbow-table attack is still possible but costly.
• NSEC5 (proposed/experimental): uses verifiable random functions; not widely deployed.

Operational guidance: use NSEC3 for zones where enumeration matters (corporate intranets, customer subdomains); NSEC is fine for public zones where the contents are already known.

2026 CA/Browser Forum requirement

CA/Browser Forum Ballot SC-085v2 (effective March 15, 2026) requires all publicly-trusted certificate authorities to validate DNSSEC when present during Domain Control Validation and CAA checks. If your domain has a misconfigured DNSSEC chain — expired signatures, broken delegation, wrong DS — the CA will refuse to issue or renew a TLS certificate until the chain is fixed. This does not mandate DNSSEC activation; zones that have never been signed are unaffected. But domains that signed their zones must now keep the chain valid or lose the ability to get new certificates.