Subject: Large typecodes and DNSSEC

From: David Blacka <[email-masked]>
Date: Tue, 28 Oct 2003 14:02:41 -0500

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    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

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

---

From: Daniel Massey <[email-masked]>
Date: Wed, 29 Oct 2003 18:22:03 -0500

On Wednesday, October 29, 2003, at 05:33  PM, Samuel Weiler wrote:

>> Type 128 is the FOO record.    The FOO record MUST be present at a 
>> name
>
> How do you prove that there should or shouldn't be a FOO?

this is bit zero in the NSIG.
bit zero = 1 proves there are types greater than 127 at this name (and 
proves there is a FOO RR that lists these types)
bit zero = 0 proves there are no type greater than 127 at this name 
(and proves there is no FOO RR at the name)

> And the FOO
> would have to be added to wildcard proofs, too.

the wildcard proof still relies on NSEC records.  You use the algorithm 
discussed the current protocol draft to prove whether the name 
exists/whether the wildcard applies.   At the end of the current NSEC 
proof, if the answer you seek is type > 127, you need the FOO RR to 
prove the type does/does not exist.

> This is too messy.
> Let's just change the NSEC format.
>
>
it is unquestionably ugly.   the intent is to make things work in the 
scenario that says:
   use format X if all type codes at this name are less than 127,
   use format Y if some types codes at this name are above 127,
   use format Z the zone is signed on tuesday, your master server has a 
black case, and your favorite type number is 3
this way lies madness and FOO RRs :)   but this is also the current 
approach and the FOO RR is intended only to make that madness work.

the clean fix is to scrap the existing format and define a **single** 
format for the NSEC type field that works for all RR types.

Dan

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Oct 2003 16:45:06 -0500

-----BEGIN PGP SIGNED MESSAGE-----

  My opinion:

>>>>> "Daniel" == Daniel Massey <[email-masked]> writes:
    Daniel> e NSECbis has "ordered list" and replaces NSEC [2]

  With ordered list as specified by Graff's "compressed" format as the
only format. Or the basic one. I don't care.

    Daniel> A simple list is more likely be done correctly.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [