Subject: Re: Large typecodes and DNSSEC

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2003 18:42:11 +0000

> 1) Is there anything wrong with the ordered list of 16-bit values
> proposed separately by Rob and Micheal (format 0)?

nope.

> 2) Since the bits for NSEC and RRSIG then take up space, do we want to
> make them implicit?  (Brian has said "no", I say "yes" -- any others
> want to speak up?)

implicit is bad.  the space savings is negligible compared to the size of
the signature and key blobs.  explicit is less error prone, or rather, will
lead to earlier signalling of logic/protocol errors, compared to implicit.

> 3) If so, do we turn the silly-state language around and say "if
> either of these typecodes is explicitly listed, treat this name as
> unsecured"?

no.

--
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: Paul Vixie <[email-masked]>
Date: Fri, 31 Oct 2003 17:55:37 +0000

> >   Use the first octet as a count of typecodes < 256, called N.  The next N
> > octets are an ascending list of 8-bit integers representing typecodes <
> > 256.  The remaining RDATA is an ascending list of 16-bit big-endian
> > unsigned integers greater than 255 representing typecodes > = 256.
> 
> I like this strawcritter.

i don't.  on a strictly puritanical basis, we need a format which can
represent all rrtypes, just in case 65535 of them are ever known to
exist and all 65535 happen to be in use at a name.  the above format
is clean but since both a DNS message and an RDATA are limited to 64K
octets, and an RDATA probably shares its containing DNS message with
some other data an RDATA is probably limited to a size slightly smaller
than 64K octets.  a bit map of 64K bits would fit.  michael's compressed
format would fit, even in the corner case of every-other-typecode in use.
if we can find something clean that is also pure, then so much the better.

> Are we completely ditching the first octet for format/reserved bits?
> If so, we're breaking the "first bit set means alternate format", but
> I think that's a safe thing to do, given the type code roll.

yes.

> If not, we need a rule for what happens when the version is greater
> than what the resolver groks.  Adapting the text I sent on Tuesday:
> "If you don't have a validated positive answer and the NSEC validates
> and you don't understand the NSEC format version, treat the name as
> unsecured."

let's avoid optional behaviour and format versioning.