skip to content

A DNSSEC registry zone with millions of mostly unsigned delegations uses NSEC3 opt-out; what does an opt-out record stop proving, and when is that acceptable?

level: seniorimportance: nice to knowfreq 9%

answer

  1. most children publish no DS
  2. a flag in each NSEC3 record
  3. spans that skip insecure delegations
  4. closest provable encloser

basics

~20 s

An opt-out NSEC3 record's span may hold unsigned delegations without asserting whether they exist, so they change without re-signing. Inside such spans unsigned delegations can be inserted or deleted undetected; signed names stay protected. Use it only in huge, sparsely signed zones.

solid answer

~50 s

Without opt-out, every delegation needs its own `NSEC3`, so each new or deleted delegation means re-chaining and re-signing. With the **Opt-Out flag** - the least significant bit of an `NSEC3` record's Flags field - set, a record's span may cover **insecure delegations** (an `NS` set with no `DS`) and asserts neither their existence nor their absence (RFC 5155 section 6). A registry then signs roughly as many `NSEC3` records as it has signed delegations and other authoritative names. The cost: inside an opt-out span, an on-path attacker can insert or delete an unsigned name, and a forged delegation lets them serve anything beneath it - though insecure delegations could already be altered. Names with signed data keep exactly the same protection. RFC 5155 says use it sparingly; RFC 9276 says it is not recommended for small zones and may be used for very large, sparsely signed ones.

go deeper

for a junior

Recall that opt-out is an NSEC3 feature that lets a zone skip unsigned delegations in its denial chain, and that it trades some proof for less signing work.

for a middle

Explain the per-record flag, what an opt-out span asserts and does not, and why a secure delegation keeps its own NSEC3 record.

for a senior

Describe the closest provable encloser proof for an unsigned referral, the insertion risk inside opt-out spans, and why RFC 8198 synthesis stops working there.

for a principal

Decide from DS adoption, delegation churn and what registrants rely on; plan to drop opt-out once enough children are signed that the saving no longer pays.

## The problem opt-out solves A registry zone is mostly **delegations**: `NS` records handing child names to their own servers. Under DNSSEC, the parent signs a `DS` record for a child that is signed, and nothing for a child that is not - an **insecure delegation**. In many registries only a small share of children publish a `DS`. Plain `NSEC3` (RFC 5155) needs one record per owner name, delegations included, all in one hash-ordered, signed chain. RFC 6781 (Informational) describes the consequence for a zone full of rarely signed, frequently changing delegations: unacceptable extra size and signing work, because every registration or deletion splices the chain and re-signs neighbours. ## How the flag works - **Per record, not per zone.** The flag lives in each `NSEC3` record. `NSEC3PARAM` at the apex keeps its Flags at 0 - an `NSEC3PARAM` with any other value is ignored. - **What a set flag means.** The record "covers zero or more unsigned delegations": hashed names of insecure delegations may fall inside its span without records of their own. - **What it still asserts.** An opt-out record makes no claim about insecure delegations in its span, but still asserts the existence or absence of all other authoritative data. - **Mixing is allowed.** A zone may mix opt-out and ordinary records. An ordinary record's span MUST NOT contain any insecure delegation; an opt-out span MUST contain only insecure delegations. - **Secure delegations are untouched.** A child with a `DS` is authoritative data in the parent, so it always has its own `NSEC3`. ## Proving a delegation is unsigned When a resolver is referred to a child, it needs proof that no `DS` exists, or it cannot tell an unsigned child from a stripped `DS`. RFC 5155 sections 7.2.7 and 8.9 give two shapes: 1. If an `NSEC3` matches the delegation name, its bitmap shows `NS` and no `DS`. 2. Under opt-out there may be none. The server then sends a **closest provable encloser** proof - the longest ancestor it *can* prove exists, plus an `NSEC3` covering the next name down - and that covering record MUST have the Opt-Out bit set. The opt-out bit is what lets the resolver accept "unsigned, unproven". The same pattern answers a direct `DS` query for such a child (sections 7.2.4 and 8.6). ## What is lost | Property | Ordinary NSEC3 span | Opt-out NSEC3 span | |---|---|---| | Existence of an insecure delegation | provable | not provable | | Inserting a fake unsigned name | detectable | undetectable | | Names with signed data | protected | equally protected | | Resolver reuse of the span (RFC 8198) | yes | no | | Re-signing when an insecure delegation is added | yes | no | RFC 5155 section 12.2 states the risk precisely: with or without opt-out, an insecure delegation can be altered undetectably, so the new loss is the ability to prove whether one **exists**. An attacker can therefore insert or delete unsigned names in an opt-out span. Because a forged delegation can point at servers the attacker controls, inserting one is as good as inserting any record type at that name and below - including names that would otherwise have been denied. Signed wildcard expansions in such spans are affected too, since the expanded name is unsigned. ## When it is acceptable - RFC 5155: use opt-out sparingly; signing tools `SHOULD NOT` default to it. - RFC 9276 section 2.2: for large, highly dynamic zones with a small percentage of signed delegations, typically registration points updating faster than real-time signing allows, or memory-constrained hardware. - RFC 9276 section 3.1: `NOT RECOMMENDED` for small zones; `MAY` be used for very large, sparsely signed zones where most records are insecure delegations. A registry deciding should ask three questions: 1. What share of delegations carry a `DS`? The smaller it is, the more opt-out saves. 2. How often do delegations change? Fast churn is what makes full re-chaining painful. 3. Do registrants rely on the zone proving that a name is *not* delegated? If so, opt-out removes exactly that. As DS adoption grows, the saving shrinks and the zone can move back to a fully chained `NSEC3`. Moving in either direction means building and signing a new chain, so it is a planned operation, not a switch flipped during an incident.

  • Why can a validating resolver not use an opt-out NSEC3 record for aggressive negative caching?
    RFC 8198 lets a resolver synthesise negative answers from a cached span only when the span proves non-existence. An opt-out `NSEC3` does not prove that names inside it are absent - an insecure delegation could be there - so RFC 8198 section 5.2 says aggressive negative caching is not possible for names it covers, and the resolver must ask the authoritative servers.
  • Does turning on NSEC3 opt-out weaken a child zone that has a DS record in the parent?
    No. A secure delegation's `DS` is authoritative, signed data, so the delegation keeps its own matching `NSEC3`, and opt-out spans may cover only insecure delegations. RFC 5155 section 12.2: names with signed data have the same security whether or not opt-out is used.

saying these in an interview costs you the question

  • Opt-out leaves every delegation unsigned, including ones whose children publish DS records.
  • Opt-out is switched on by setting the Flags field of the apex NSEC3PARAM record.
  • An opt-out NSEC3 record still proves that no unsigned delegation exists in its span.
  • Opt-out is the sensible default for any zone signed with NSEC3.
  • With opt-out a missing DS can no longer be proven, so every unsigned referral validates as bogus.