Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag)

[Roy Badami <roy@gnomon.org.uk>]

>>>>> "David" == David Blacka <davidb@verisignlabs.com> writes:

    David> It is possible that you are using a different set of
    David> assumptions than I am.  I'm assuming that Charlie, when it
    David> doesn't understand NSEC2, operates under the current
    David> DNSSECbis specs.

Possibly.  I am assuming that DNSSECbis is modified so NSEC RRs
contain a version field, which is set to 1 (say).  I am also assuming
that when a DNSSECbis resolver sees a response in which all the NSEC
RRs have a version greater than 1 (and those RRs are correctly
signed), it treats the response as insecure, rather than bogus.

The question is, would this allow the subsequent introduction of a
version 2 NSEC record in a relatively painless manner?

I assert that the null DS record would make such introduction more
painless.  The main cost (increased zone size) is borne by those who
want to use later versions of NSEC, though it does of course add a
(small) additional complexity to DNSSECbis resolvers.

    David> I absolutely agree with this.  However, even though we may
    David> now think we know what NSEC2 looks like, if we pursue this
    David> versioning path, we will have to assume that we do not
    David> actually know what future NSEC-like records will look like.
    David> That makes it pretty difficult to figure out how to
    David> compensate for it, I think.

That's true.  But null DS records don't rely on having any NSEC-like
records at all.  So it would seem to me that they can complensate for
_any_ change to NSEC.

      -roy


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