skip to content

For a DNSSEC hosting platform signing many customer zones, how do you choose between precomputed NSEC3, RFC 4470 minimally covering NSEC and RFC 9824 compact denial?

level: principalimportance: should knowfreq 6%

answer

  1. where the private key lives
  2. can resolvers reuse the span
  3. NXDOMAIN or NOERROR
  4. signatures per negative answer

basics

~20 s

Precomputed NSEC3 keeps keys off the servers and lets resolvers reuse spans, but leaks guessable names. Minimally covering NSEC and compact denial stop enumeration but need online keys and leave no reusable spans; compact denial also turns NXDOMAIN into NOERROR.

solid answer

~50 s

Start from where keys must live. If zones are signed ahead of time, precomputed `NSEC` - or `NSEC3` with RFC 9276's `1 0 0 -` where policy demands - needs no key on the servers and lets validating resolvers answer whole gaps from cache (RFC 8198), which absorbs random-subdomain floods; the price is an enumerable or dictionary-guessable zone. If the servers sign online anyway, **minimally covering** records (RFC 4470 for `NSEC`; the `NSEC3` variant is dubbed 'white lies') make walking as costly as guessing, but sign up to two `NSEC` or three `NSEC3` records per negative answer. **Compact denial** (RFC 9824) answers a missing name as no-data with one `NSEC` carrying the `NXNAME` type: the smallest response and least signing, but `NOERROR` replaces `NXDOMAIN` unless the CO flag restores it, and no online scheme leaves spans resolvers can reuse. Decide on key custody, CPU budget, NXDOMAIN visibility and flood absorption.

go deeper

for a junior

Recall that a zone can prove absence with records signed in advance or signed per query, and that per-query signing needs the key on the servers.

for a middle

Explain how minimally covering records and compact denial differ from a precomputed chain, and what the NXNAME type signals in an NSEC bitmap.

for a senior

Predict the side effects of compact denial: NOERROR in place of NXDOMAIN, extra lookups from clients, and the loss of resolver-side synthesis under random-subdomain floods.

for a principal

Own the platform choice: key custody, signing capacity, customers' reliance on NXDOMAIN and flood absorption decide it, and different customers may need different answers.

## The options side by side | Approach | Signed when | Enumeration | Denial records per missing name | Resolver span reuse (RFC 8198) | Response code | |---|---|---|---|---|---| | Precomputed `NSEC` | zone signing | walkable | up to 2 | yes | `NXDOMAIN` | | Precomputed `NSEC3`, `1 0 0 -` | zone signing | hashes, dictionary-guessable | up to 3 | yes, except opt-out spans | `NXDOMAIN` | | Minimally covering `NSEC` (RFC 4470) | per query | impractical | up to 2, signed on demand | no | `NXDOMAIN` | | `NSEC3` "white lies" (RFC 7129 Appendix B, Informational) | per query | impractical | up to 3, signed on demand | no | `NXDOMAIN` | | Compact denial (RFC 9824) | per query | impractical | 1 | no | `NOERROR`, with `NXNAME` | **Minimally covering** records replace the real gap with a tiny invented one: an owner name just before the query name and a next name just after it, produced by "epsilon" functions and signed on the spot. RFC 4470 shows they make walking take about as many queries as guessing every name. **Compact denial** goes further: it claims the missing name exists with no data of the queried type and proves that with one `NSEC` whose owner is the query name, whose next name is its immediate successor, and whose bitmap holds `RRSIG`, `NSEC` and the meta-type `NXNAME` (128). ## What online signing costs RFC 4470 section 5 and RFC 9824 section 8 list the price of any online scheme: - **Key custody.** Every internet-facing authoritative server must hold the zone's private signing key, which raises the chance of disclosure. If a platform's policy or its customers' contracts require keys to stay offline, every online scheme is ruled out before any other comparison. - **CPU as an attack surface.** Signing on demand costs far more than serving stored signatures, so floods of negative queries become a computational denial-of-service. Compact denial signs fewer records than minimally covering answers, and RFC 9824 recommends algorithms with a low signing cost, such as elliptic-curve ones. - **Epsilon quality.** RFC 4470 warns that predictable generated names can be reverse-engineered, and could enable chosen-plaintext attacks on the key. How keys are split and protected on an online signer is a signing-design question; for denial, what matters is that every online method requires keys on the servers. ## The NXDOMAIN visibility problem Under compact denial, a server answering a query with the DO bit set never returns `NXDOMAIN` unless both sides use RFC 9824's optional **Compact Answers OK (CO)** flag, an EDNS header flag. The consequences an operator must plan for (RFC 9824 sections 5, 6 and 8): 1. Monitoring and security tools that count `NXDOMAIN` see `NOERROR` instead and must learn to read `NXNAME` in the bitmap. 2. Address-lookup functions may send an extra query for the other address type after a no-data answer, where `NXDOMAIN` would have stopped them. 3. A validating resolver may restore `NXDOMAIN` for clients that did not set DO, and for clients that set CO. 4. The `NXNAME` bit is signed data while the header code is not, so it is the more trustworthy signal; it also tells a missing name apart from an empty non-terminal, whose bitmap holds only `RRSIG` and `NSEC`. ## Flood absorption RFC 8198 lets a validating resolver answer any name inside a cached, validated span itself, which cuts the random-subdomain floods that otherwise reach the authoritative servers. RFC 9824 section 6 notes that **no** online scheme built on minimally covering records permits this: each span covers only the name asked about. A platform choosing online denial is choosing to absorb those floods on its own servers. ## A decision path 1. **Can keys live on the edge?** If not, use precomputed `NSEC`, or `NSEC3 1 0 0 -` for customers whose policy forbids handing out their name list. 2. **Does the platform already sign online** (answers generated per query)? If so, precomputed chains are not an option, and the choice is between minimally covering records and compact denial. 3. **Who depends on `NXDOMAIN`?** If customers' tooling does and resolvers on the path do not yet restore it, minimally covering `NSEC` keeps the familiar code; otherwise compact denial with CO support is cheaper. 4. **Capacity.** Size authoritative capacity and rate limiting for floods resolvers can no longer absorb. 5. **Revisit.** RFC 9824 itself says that if response size and signing cost are not the concern, conventional online signing or precomputed signatures avoid the NXDOMAIN visibility problem altogether. There is no single right answer: a platform with offline keys and public names is best served by plain `NSEC`, and an edge network that signs every answer on demand is pushed toward compact denial.

  • How does a compact-denial answer for a missing name differ from one for an empty non-terminal?
    Both are no-data answers with one `NSEC` whose owner is the query name. For a missing name the bitmap holds `RRSIG`, `NSEC` and `NXNAME`; for an empty non-terminal, which really exists, it holds only `RRSIG` and `NSEC` (RFC 9824 sections 2 and 3.2). With `NSEC3`, the missing name's bitmap holds only `NXNAME` and the empty non-terminal's is empty.
  • When can a validating resolver hand NXDOMAIN back to its clients for a compact-denial answer?
    RFC 9824 section 5 lets it rewrite `NOERROR` to `NXDOMAIN` for clients that did not set the DO bit, and, with the optional CO flag, for DNSSEC clients that signal they accept it. CO is hop-by-hop EDNS, so the resolver must record it with the cached answer and reset the code to `NOERROR` for clients that did not send CO.

saying these in an interview costs you the question

  • Compact denial still returns NXDOMAIN to DNSSEC-aware clients by default.
  • Minimally covering NSEC records need no private key on the authoritative servers.
  • Online denial schemes let resolvers absorb random-subdomain floods from cached spans.
  • Raising NSEC3 iterations is how an online signer stops zone enumeration.
  • Precomputed NSEC requires the authoritative servers to hold the zone's private key.