A DNSSEC-validating resolver looks up a name in shop.example.com, delegated from signed example.com with no DS; why is the answer insecure rather than bogus, and what must the resolver see first?

## Four outcomes, two of them easily confused A validating resolver sorts every answer into one of four states, defined in RFC 4033 Section 5 and RFC 4035 Section 4.3: | State | What the resolver has | What happens to the answer | |---|---|---| | **Secure** | an anchor and an unbroken chain of DS and DNSKEY RRsets to the data, all signatures verify | returned as validated | | **Insecure** | an anchor, a chain, and *signed proof* that some delegation on the path has no DS | returned without validation | | **Bogus** | an anchor and a secure delegation saying the data should be signed, but validation fails | treated as a failure | | **Indeterminate** | no anchor covering the name | returned without validation (the default mode) | **Insecure** and **bogus** both describe data that did not validate. The difference is whether the chain *promised* signatures. Insecure means the signed tree itself said "below here, nothing is signed". Bogus means the tree said "this should be signed" and the answer failed that promise. A bogus answer reaches a stub resolver as a server failure; that signalling belongs to validation. An insecure answer is returned normally. ## The scenario: shop.example.com has no DS `example.com` is signed and chains to the root. It delegates `shop.example.com` to another team's name servers, and no `DS` was ever placed in `example.com` for it. Perhaps the subzone is unsigned. Perhaps it is signed but nobody uploaded its digest, which makes it an *island of security*. What the resolver does: 1. It asks `example.com`'s servers about a name under `shop.example.com` and gets a **referral**: the delegation `NS` RRset. That RRset is never signed at a delegation point, so it proves nothing on its own. 2. Under RFC 4035 Section 3.1.4, a security-aware server answering with the DO bit set MUST include the `DS` RRset and its signatures if one exists. If not, it MUST include the `NSEC` record proving there is no `DS`, with its `RRSIG`. 3. The resolver authenticates that `NSEC` with `example.com`'s trusted keys. It shows the delegation name with `NS` in its type map but no `DS`. 4. If the referral carried neither a `DS` nor such a proof, the resolver **MUST query the parent zone's servers for the DS RRset** (RFC 4035 Section 5.2). 5. With absence proven, RFC 4035 says there is "no authentication path leading from the parent to the child". Data in and below `shop.example.com` is insecure, and validation of that subtree stops. Two details matter here: - **Use the parent's proof.** A signed delegation has two `NSEC` records at the same name: one in the parent and one at the child's apex. RFC 4035 says the resolver MUST use the parent's, which can be told apart because the SOA bit is clear in it and set in the child's. - **Hashed denial works the same way.** In zones using `NSEC3`, the proof is an `NSEC3` record for the delegation whose type map has no DS bit. With **opt-out**, an insecure delegation may have no `NSEC3` of its own and is covered by a span flagged opt-out. Those proof mechanics belong to authenticated denial. ## Why a missing DS is not enough RFC 4035 Section 5 is blunt: "The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists." From the defender's side, that rule closes a **downgrade**. An on-path attacker who could delete a `DS` from a referral, and have the resolver shrug and treat the child as unsigned, would switch off DNSSEC for any zone they liked. Requiring a *signed* denial means only the parent's keys can declare a child unsigned. A stripped `DS` leaves the resolver unable to prove absence: it asks the parent directly, and if the attacker blocks that too, the answer ends up bogus, never insecure. ## Other roads to insecure - **Unsupported algorithms.** RFC 4035 Section 5.2 says that if the resolver supports none of the algorithms in an authenticated DS RRset, it should treat the child as unsigned. RFC 9905 now requires operators to treat `DS` records using RSASHA1 (5) or RSASHA1-NSEC3-SHA1 (7) as insecure, and the data below as insecure if no other `DS` remains. - **Local policy.** RFC 4033 lets a resolver operator mark parts of the namespace insecure, for example to ride out someone else's broken zone. - **A deeper anchor.** If the resolver holds a configured key for `shop.example.com` itself, RFC 4035 lets it re-establish the chain from that anchor. ## What this means for operators - Signing `shop.example.com` without getting its `DS` into `example.com` buys **no protection** from validating resolvers. Nothing fails, so nobody notices. - The reverse mistake, a `DS` in the parent that matches no published key, makes the child **bogus** and unreachable for validating clients. That outage usually comes from a botched key rollover. - An unsigned delegation inside a signed zone is legitimate and common; insecure is a valid result, not an error.