CONCEPT Cited by 1 source
DNSSEC chain of trust¶
Definition¶
The DNSSEC chain of trust is the transitive authority chain from the DNS root zone down to an individual signed DNS record. Each parent zone vouches for the authenticity of its children's signing keys via a DS (Delegation Signer) record — a cryptographic hash of the child zone's Key Signing Key (KSK) public key. The root zone's trust anchor is hardcoded in resolver software, making the root the universal anchor every chain terminates at.
From the 2026-05-06 Cloudflare
DNSSEC .de outage post:
"DNSSEC is built on a chain of trust. Starting at the root zone, whose trust anchor is hard-coded into the resolvers, each zone delegates trust to child zones via Delegation Signer (DS) records. A DS record in the parent zone contains a cryptographic hash of a public key in the child zone. When a resolver validates
example.deit verifies the chain: root trusts.de,.detrustsexample.de."
The chain (bottom-up)¶
Validating example.de from a resolver's perspective:
example.dezone: records signed byexample.de's ZSK. ZSK signed byexample.de's KSK..dezone (parent): contains a DS record forexample.dewhose hash matchesexample.de's KSK. The DS record itself is signed by.de's ZSK..de's ZSK is signed by.de's KSK.- Root zone (
., grandparent): contains a DS record for.dewhose hash matches.de's KSK. Root's DS record is signed by root's ZSK. Root's KSK public key is the hardcoded trust anchor.
If every RRSIG verifies against the DNSKEY the link above
names, the chain is intact and example.de's records are
authentic.
Why a break anywhere breaks everything below¶
The defining failure property:
"A break anywhere in that chain causes validation to fail for everything below it, which is why a misconfiguration at a TLD like
.deaffects every domain under it."
Mechanism: a validator cannot accept records from a child zone unless the child's DNSKEY is authenticated via the parent's DS record + the parent's own signatures. If the parent publishes signatures the validator cannot verify, no child under that parent has a valid chain — regardless of how correctly the children have signed their own zones.
This is what makes DNSSEC failures at TLD altitude structurally worse than failures at second-level altitude: the blast radius is "every domain under that TLD" instead of one domain. See concepts/tld-level-failure-blast-radius.
The hardcoded root trust anchor¶
The chain has to terminate somewhere. For DNSSEC, that somewhere is the IANA root zone, whose KSK public key is shipped in every validating resolver's software distribution. This is the one link in the chain not itself authenticated by a higher link — resolvers have to trust the root KSK from first principles.
See concepts/trust-anchor-distribution for the broader pattern (the root DNSKEY is the "hardcoded in the client binary" shape of trust-anchor distribution, sibling to OTA-validation-bundle and attestation-against-ledger shapes).
Rotating the root KSK therefore requires a coordinated software-update flow across every validating resolver on the Internet — the 2018 root KSK rollover was managed over multiple years with public telemetry and phased rollouts for exactly this reason.
TLD-level vs root-level rotation¶
| Altitude | Rotation difficulty | Rotation failure blast radius |
|---|---|---|
| Leaf zone ZSK | Easy — just re-sign records, wait for caches | Only that zone |
| Leaf zone KSK | Harder — parent's DS record must update, requires registrar coordination | Only that zone |
| TLD ZSK | Moderate — TLD-internal mechanical rotation | Every domain under the TLD (the DENIC .de case) |
| TLD KSK | Hard — root's DS record for the TLD must update | Every domain under the TLD + cross-org coordination |
| Root KSK | Very hard — requires coordinated software rollout across every resolver | Every signed domain on the Internet |
DENIC's 2026-05-05 rollover failure hit at the TLD-ZSK altitude
and affected every .de domain simultaneously. That failure
would not be recoverable via an NTA on a single domain; the
mitigation has to be applied at the TLD altitude — hence
concepts/negative-trust-anchor declared at the .de level.
Seen in¶
- sources/2026-05-06-cloudflare-when-dnssec-goes-wrong-de-tld-outage — canonical wiki instance of the chain-of-trust structure with the "a break anywhere in that chain causes validation to fail for everything below it" framing quoted verbatim. DENIC's 2026-05-05 TLD-ZSK-rotation misfire is the canonical cascading-failure worked example.
- sources/2026-05-01-meta-strengthening-end-to-end-encrypted-backups — sibling at a different substrate: Meta's E2EE-backup key distribution also uses a chain-of-trust (client → signed validation bundle → HSM fleet public keys), with third-party countersignature protecting the top of the chain. DNSSEC's root KSK is the single-signer version of the same pinning problem.
Related¶
- concepts/dnssec — the parent concept; this page specialises on the chain/hierarchy property.
- concepts/tld-level-failure-blast-radius — the structural hierarchy-amplification property the chain creates.
- concepts/signing-key-rotation-lifecycle — how to rotate a link without breaking validators below it.
- concepts/trust-anchor-distribution — the root-KSK hardcoded-in-client shape belongs to a broader family.
- concepts/negative-trust-anchor — the mitigation that surgically breaks the chain at a named zone during an incident.