How does RFC 5011 let a DNSSEC-validating resolver accept a new root key-signing key in-band, and why does it impose a 30-day add hold-down?
answer
- old anchor vouches for new key
- AddPend before Valid
- a compromised key could add its own
- time to notice and revoke
- REVOKE bit, self-signed, immediate
basics
~20 sUnder RFC 5011, a new SEP key in a DNSKEY RRset validated by a current anchor becomes a trust anchor only after an add hold-down of at least 30 days, giving the owner time to revoke a stolen key first.
solid answer
~50 sRFC 5011 (STD 74) lets existing trust anchors authenticate their successors at the same trust point, such as the root. When a resolver sees a new key with the SEP bit in a root `DNSKEY` RRset that validates against a current anchor, the key enters **AddPend** and a timer starts. The add hold-down is 30 days, or the expiry of the RRset's original TTL if longer. After the hold-down, the next validated RRset that still contains the key makes it **Valid**. The delay exists because a stolen anchor key could otherwise add an attacker's key at once. With it, the owner has a window to revoke the stolen key: it publishes the key with the REVOKE bit (flags bit 8) and signs the RRset with that same key, which takes effect immediately. RFC 9718 provides the first anchor; RFC 5011 keeps it current.
go deeper
Recall that root keys change and that resolvers can learn a new root key in-band, but only after a waiting period of at least 30 days.
Explain the AddPend-to-Valid path, the reset when the key disappears, and the REVOKE bit that must be self-signed. Compute a query interval from a TTL and a signature lifetime.
Discuss operating it: resolvers restored from old images missing a rollover, the trust-point deletion rule, and how key-tag signalling and the sentinel measure adoption before the old key goes.
Weigh automated in-band anchor updates against managed out-of-band distribution across a fleet, including who watches root key announcements and how a stale anchor is detected before it causes an outage.
## The problem RFC 5011 solves A validating resolver trusts the root zone because it holds a configured **trust anchor**, a copy or digest of the root's key-signing key (KSK). That key does not last for ever. RFC 9718's example anchor file lists KSK-2017 (key tag 20326) and KSK-2024 (key tag 38696), and every change of the root KSK must reach every resolver that validates. Reconfiguring them all by hand does not scale. RFC 5011, *Automated Updates of DNS Security (DNSSEC) Trust Anchors* (STD 74), lets the keys a resolver already trusts introduce their successors **in-band**, through ordinary DNS. RFC 9718 calls itself "a complement to, not a substitute for" RFC 5011. The anchor file is how a resolver gets its *first* anchor; RFC 5011 is how it follows changes afterwards. ## How a new key is accepted RFC 5011 tracks each key at a **trust point** (here the root) through a normative state table: | State | Meaning | |---|---| | `Start` | not yet a trust anchor at this resolver | | `AddPend` | seen with the SEP bit in a validated `DNSKEY` RRset; hold-down running | | `Valid` | in every validated RRset through the hold-down; now a trust anchor | | `Missing` | still valid, but absent from the last validated RRset (abnormal) | | `Revoked` | seen with its REVOKE bit set in an RRset it signed; never trusted again | | `Removed` | forgotten after the remove hold-down | The acceptance sequence: 1. The zone owner adds a new `DNSKEY` with the SEP bit to the root `DNSKEY` RRset, signed by the current key-signing key. 2. The resolver validates that RRset against its existing anchor, sees the new key and moves it to `AddPend`. It remembers which keys validated the RRset. 3. If the resolver later sees a validly signed RRset *without* the new key, it stops and resets the timer. 4. When the **add hold-down** expires, the key becomes a trust anchor the next time a validated RRset containing it is seen. RFC 5011 says the resolver MUST NOT trust it before both conditions hold. The add hold-down is **30 days, or the expiration of the original TTL of the first DNSKEY RRset that contained the new key, whichever is greater**. That guarantees at least two validated sightings before acceptance. ## Why the hold-down exists Suppose an attacker steals the private half of one current anchor key. Without a delay, they could add their own key to the RRset, sign it with the stolen key, and have every resolver accept it as a new anchor at once. The hold-down turns that into a race the owner can win. For 30 days the attacker's key sits in `AddPend`. During that time the owner can notice and revoke the compromised key, and if every key that vouched for the newcomer is revoked first, its acceptance stops. RFC 5011 is honest that this mitigates rather than solves the problem. An attacker who controls everything one resolver sees can keep that resolver in the dark. ## Revocation Bit 8 of the `DNSKEY` Flags field is the **REVOKE** flag. A key-signing key normally has flags 257 (Zone Key plus SEP); with REVOKE set it reads 257 + 128 = **385**. A revocation counts only when the revoked key appears in a `DNSKEY` RRset **signed by that same key**, so only the holder of its private key can revoke it. Unlike adding, revocation is **immediate and permanent**. Setting the bit changes the key's digest and key tag, so it no longer matches the old fingerprint. The **remove hold-down** of 30 days only governs when the resolver may forget a revoked key; it is bookkeeping. ## Staying in touch A resolver doing automated updates MUST re-query the trust point's `DNSKEY` RRset at least every: `queryInterval = MAX(1 hr, MIN(15 days, 1/2 * OrigTTL, 1/2 * RRSigExpirationInterval))` For example, with an original TTL of 2 days and an RRSIG that expires in 10 days, MIN(15 days, 1 day, 5 days) = 1 day, so the resolver must look at least daily. These are illustrative values, not the root's. ## Operating it - A resolver must manage at least five SEP keys per trust point. - A resolver that is offline, or deployed from an old image, through a whole rollover never sees the overlap. If it returns after the old key has left the RRset, it holds an anchor the zone no longer signs with, so it cannot authenticate the root's keys, and validation fails until its anchor is replaced out of band. - If a resolver sees *all* anchors at a trust point revoked, RFC 5011 deletes the trust point and treats data below it as insecure, unless a superior anchor exists. - Accepting updates is the resolver owner's decision, not the zone's. Disabling RFC 5011 means taking on manual anchor updates. - To see who has picked up a new key, RFC 8145 lets resolvers signal the key tags they trust, and RFC 8509 adds sentinel labels that reveal a resolver's root anchor.
- Why does RFC 5011 require a key to sign its own revocation, rather than letting another trusted key revoke it?If any anchor could revoke another, an attacker with one stolen key could revoke every legitimate key and leave only theirs. Requiring the revoked key's own signature means only its private-key holder can revoke it. In RFC 5011's example, the attacker holding B can revoke B but not A. The owner can still revoke the stolen B, since the owner holds it too.
- Under RFC 5011, a validating resolver was powered off through an entire root key-signing key rollover; what happens when it comes back?It never saw the new key during the overlap, so that key never became an anchor. If its old anchor is no longer in the root `DNSKEY` RRset, it cannot authenticate the root keys and validation fails across the board. If it sees the old key published as revoked and that was its only anchor, RFC 5011 deletes the trust point and treats data as insecure. Either way it needs a fresh anchor out of band, such as IANA's RFC 9718 file.
- How can a root key operator tell whether validating resolvers have picked up a new key under RFC 5011?RFC 8145 defines optional key-tag signalling: a resolver lists the key tags it trusts in an EDNS option on DNSKEY queries, or sends special key-tag queries, so authoritative operators can count adoption. RFC 8509 adds the root key sentinel, query labels that let anyone test whether a given resolver trusts a given root key tag. Both measure readiness; neither changes how keys are accepted.
saying these in an interview costs you the question
- A resolver trusts a new root key as soon as it appears in a validly signed DNSKEY RRset.
- Revoking a trust-anchor key takes effect only after the 30-day hold-down.
- Any current trust anchor can revoke another key at the same trust point.
- The hold-down only lets caches expire and has no security purpose.
- RFC 5011 removes the need for any initially configured trust anchor.