Subject: NSEC3 design FAQ

From: Samuel Weiler <[email-masked]>
Date: Fri, 28 Oct 2005 14:08:59 -0400 (EDT)

I've collected some of the questions I've gotten about the design of
NSEC3.  Here they are along with my own answers.  It's clear that
others have different perspectives, particularly about the need for
signaling -- again, these are MY answers.  Hopefully they'll be useful
to others.

Q: Why can't the hash string for an NSEC3 RR go in its RDATA instead
   of the owner name?

A: It can, so long as two hashes appear in the RDATA.  For more
   details, see
   http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00683.html

Q: But why won't a single hash work?

A: Two reasons.

   The first: so long as the owner name of the NSEC3 RR's includes a
   real name, the zone can be walked.  (This is true so long as the
   owner name of the NSEC is obviously related to the QNAME (e.g. the
   closest preceding existing name) -- having a real owner name
   appear that is unrelated to the QNAME might work, but hasn't been
   explored much.)

   The second: NSEC proofs wouldn't work.  NSEC (and NSEC3) proofs
   both rely on the NSEC/NSEC3 specifying a range of names (or a range
   of hashes) between which there are no records (or no records other
   than delegations, for the 'delegation-only' or 'opt-in'
   variations).  NSEC specifies a range of real names.  NSEC3
   specifies a range of hashes.  Specifying one real name and one hash
   does not specify a range, so a validator can't check whether a
   QNAME is covered by such a record, hence whether or not the proof
   is valid.

Q: Why do we have to mark a zone as using NSEC3?

A: What happens if a legacy (NSEC-only) resolver attempts to validate
   an NSEC3-only zone without having been told that this is an
   NSEC3-only zone?  Any answer requiring an nonexistence proof
   (NXDOMAIN, name errors, wildcard synthesis, unsecure delegations)
   will lack the requisite NSEC RR's, hence result in a validation
   failure.  This would provide a tremendous incentive to not sign
   zones with NSEC3 -- doing so would generate these spurious
   validation failures.  Instead, we need to somehow make the legacy
   resolvers think that the new zone is unsecure.

Q: But why can't we just add a new RR type at the zone apex to signal
   the use of NSEC3?

A: A legacy (NSEC-only) resolver won't know to check for that RR.
   Absent some other signaling mechanism that it understands, it will
   expect the zone to be secured and provide NSEC RR's as needed.
   When the zone doesn't do that, all answers requiring a nonexistence
   proof will be treated as Bogus.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>