In DNSSEC, what is a trust anchor, and why must a validating resolver be configured with the root's key instead of learning it from DNS?

## What a trust anchor is DNSSEC lets a resolver check that DNS data really came from the zone that owns it and was not altered on the way. It does this with signatures, and a signature is only worth something if you trust the key that checks it. Every key in DNSSEC is trusted because another key vouched for it, all the way up the tree. At the top that regress has to stop somewhere, and the place where it stops is the **trust anchor**. RFC 4033 defines it precisely: a trust anchor is "a configured DNSKEY RR or DS RR hash of a DNSKEY RR" that a validating resolver uses "as a starting point for building the authentication chain". RFC 9718 adds the general idea: a trust anchor is an entity "for which trust is assumed and not derived". Two forms are therefore allowed: - **A `DNSKEY` record** - the public key itself. - **A DS-style digest** - the key tag, algorithm, digest type and a hash of the key, in the same shape as a `DS` record. The resolver then fetches the real `DNSKEY` and checks it against the hash. For most resolvers the only anchor is the one for the **root zone**, because a single root anchor lets it validate any signed zone under the root. ## Why it cannot come from DNS itself The whole point of DNSSEC is that DNS answers can be forged. If a resolver bootstrapped its root key by querying the root servers for their `DNSKEY` RRset and trusting whatever came back, the very attacker DNSSEC is meant to stop could answer that query with a key of their own. Every signature they then produced would check out against the key they planted. So RFC 4033 says a validating resolver "will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol", and RFC 4035 Section 4.4 asks for a robust way to have it at boot, such as non-volatile storage. This is the same circularity every public-key system faces: you cannot use a channel to prove the key that secures that channel. ## How the root anchor is published RFC 9718 (Informational, January 2025, obsoleting RFC 7958) describes how IANA publishes the root anchors. The format is an XML document with one `KeyDigest` element per past, current or future root key: | Element | Meaning | |---|---| | `KeyTag` | the key tag of the root `DNSKEY` it describes | | `Algorithm` | the signing algorithm number, 8 (RSASHA256) for both keys in RFC 9718's example | | `DigestType` | the hash used, 2 (SHA-256) | | `Digest` | the hash, in the same form as a `DS` record | | `validFrom` / `validUntil` | the window in which the entry may be used as an anchor | | `PublicKey` + `Flags` | optional; the key itself, flags 257 for a key-signing key | The example in RFC 9718 yields two DS records for the root: key tag **20326** (KSK-2017) and key tag **38696** (KSK-2024), both algorithm 8, digest type 2. An older key, tag 19036, appears only with a `validUntil` in the past and is excluded from the set. To help operators trust the file itself, IANA serves it over HTTPS and adds a detached CMS signature. RFC 9718 is explicit that the CA behind that signature "is not a DNSSEC trust anchor" - it only helps you check the file's origin. ## What the resolver does with the anchor RFC 4035 Section 5 lists what the resolver must check before it trusts the root's key set: 1. The anchored key appears in the root's apex `DNSKEY` RRset and has the Zone Key flag set. 2. An `RRSIG` covering that `DNSKEY` RRset verifies with the anchored key. 3. Every other key in that RRset is now trusted, and the walk down the tree can begin. If the anchor is a digest, the resolver first hashes the fetched `DNSKEY` and compares. ## Keeping it current, and other anchors A root key-signing key is replaced from time to time, so an anchor cannot be configured once and forgotten. RFC 5011 lets a resolver that already trusts the current key accept a successor in-band, after a hold-down period. RFC 9718 calls itself a complement to RFC 5011, not a substitute: the file is how you get the *first* anchor. Local policy may also add anchors for other zones. RFC 4035 Section 4.4 says a resolver SHOULD accept several. An **island of security** is a signed zone with no `DS` in its parent. It can be validated only if its key is configured as an anchor, out of band. ## What happens without one A resolver with no anchor covering a name cannot tell whether that data should be signed. RFC 4033 calls this state **Indeterminate** and describes it as the default mode. The resolver still answers, but it checks nothing and protects nothing.