Large typecodes and DNSSEC

[David Blacka <davidb@verisignlabs.com>]

Currently the NSEC record (nee NXT) can only support typecodes up to
127 (dnssec-records-05, section 4.1.2).  However, the type field in
DNS is actually 16 bits long.

While this situation has been true for as long as I've been looking at
DNSSEC, and presumably since its inception, this is an issue that
seems to have been totally ignored by this WG.

I would like to know:

  * How can we consider DNSSEC complete while it ignores 9 of the 16
    bits in the typecode field?

  * What happens when (or if), after this current DNSSEC spec is
    widely deployed, we want to define typecode 128?  Do we do another
    typecode rollover? Move the DO bit? add another EDNS flag?

In the current form, I feel that DNSSEC will artificially constrain
DNS typecodes to no larger than 127, simply because existing
implementations of DNSSEC-aware DNS software will not be able to
handler larger typecodes, and we all know how much of a PITA getting
everyone to roll out new DNS software is.

  * If the intention is the constrain the typecode field to 7
    effective bits, then please explain why.  Is the intent to reserve
    the remaining 65407 types for psuedo types?

  * Why haven't we already defined the alternate format of the NSEC
    typecode field?  Are we waiting for some future breakthrough that
    will allow us to handle these giant numbers between 128 and 65535?

This WG has spent a fair amount of time on other issues of forward
compatibility, but why not this?

-- 
David Blacka    <davidb@verisignlabs.com> 
Sr. Engineer    Verisign Applied Research


--
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/>