"Olaf M. Kolkman" <olaf <at> ripe.net> writes:

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

I already answered, but as "yes" or "no" sounds more like opinions
than technically motivated answers, here is something I believe would
complicate NSEC-alt in the future if DNSSECbis is advanced.  Section
2.3:

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record. The
   process for constructing the NSEC RR for a given name is described in
   [I-D.ietf-dnsext-dnssec-records].

The behaviour for when the MUST is not followed, such as if lying NSEC
is used, are not described.  It is conceivable that a validating
resolver treat missing NSEC's for authoritative data in a zone as a
protocol error, and label the zone as bogus, and return SERVFAIL to a
CD=0 client.

Depending on how resolvers implement the above requirement, this might
prevent lying NSEC.

It might simplify migration if the presence of NSEC RR was not a
protocol requirements, but instead the validation logic simply
returned "insecure" (for questions with positive answers) or "bogus"
(for questions with negative answers) when a NSEC is missing.  This
would be a larger change, so I'm not proposing to do this, just that
it can be considered.

Thanks,
Simon

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