Subject: Re: nsec++

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 14:29:32 +0100

[On 27 Nov, @16:21, Jakob wrote in "nsec++ ..."]
> my initial version of the draft respecifying the rdata format for nsec has
> been submitted to the drafts editor and can also be found at the following
> address:
> 
>   http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-00.txt

i'm looking at the draft from:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-00.txt

I have made the following observations:

1. Introduction:

   amount of space it uses for the common case of a few types with an
   owner name; that it can represent owner names with all possible type
   present in packets of approximately 8.5 kilobytes; that the
   representation is simple to implement. Efficient searching of the
 
I didn't closely follow the NSEC discussion...but where is this 8.5 kilobytes
coming from?

2.1.2 The List of Type Bit Map(s) Field:

   the bitmap MUST be removed. Blocks is presented in increasing
   numerical order.

   "|" denotes concatenation
   
   NSEC RDATA = ( Window Block # | Bitmap Length | Bitmap ) +

Shouldn't that be:

Type Bit Map = ( Window Block # | Bitmap Length | Bitmap )

or

Type Bit Maps = ( Window Block # | Bitmap Length | Bitmap ) +

Also I only now notice the '+', more that can be made more explicit.

I'm also missing some text on how to calculate the type from the
bitmap (although that would not be difficult).

I assume something like: Window Block # * 256 + Bit # (in Bitmap).

2.3 NSEC RR Example:

Maybe it is an idea to also include the NSEC RR with integers instead
of RRtypes, thus:

alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
or
alfa.example.com. 86400 IN NSEC host.example.com. 1 23 47 48 
(i'm too lazy to lookup the correct typecodes for the types)

This integer stuff, was that already in the NXT record? If not,
why is it here? (unknown RRs probably). Can I mix integers and
real types in a NSEC RR?

grtz Miek

--
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: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Dec 2003 14:52:37 +0100 (CET)

On Wed, 3 Dec 2003, Miek Gieben wrote:

>  I didn't closely follow the NSEC discussion...but where is this 8.5
> kilobytes coming from?

worst case is 256 blocks, each represented using 34 bytes. this results in
about 8.5 kbytes.

> Also I only now notice the '+', more that can be made more explicit.

I suggest the 2nd version since it is a list of bit maps. or should we
write something like:

NSEC RDATA = Next Domain Name |
             ( Window Block # | Bitmap Length | Bitmap ) +

> I assume something like: Window Block # * 256 + Bit # (in Bitmap).

please send text.

> why is it here? (unknown RRs probably).

unknown RRs can be represented either as integers or TYPE# notation.

> Can I mix integers and real types in a NSEC RR?

the current text does not allow mixing I think.

	jakob

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 14:58:07 +0100

[On 03 Dec, @14:52, Jakob wrote in "Re: nsec++ ..."]
> worst case is 256 blocks, each represented using 34 bytes. this results in

ahh, so simple :)

>              ( Window Block # | Bitmap Length | Bitmap ) +

The paragraph is called "2.1.2 The List of Type Bit Map(s) Field", so 
I think my second suggestion is more consistent.

> > I assume something like: Window Block # * 256 + Bit # (in Bitmap).

will do,

> the current text does not allow mixing I think.

maybe it should say that?

grtz Miek

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Dec 2003 15:01:51 +0100 (CET)

> maybe it should say that?

I think it already does:

"The Type Bit Map field is represented either as a sequence of RR type
mnemonics or as a sequence of unsigned decimal integers denoting the RR
type codes."

i.e., one type of sequence OR another type of sequence. if it allowed
mixing, it would probably say:

"The Type Bit Map field is represented as a sequence of RR type mnemonics
or unsigned decimal integers denoting the RR type codes."

	jakob

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 15:05:04 +0100

[On 03 Dec, @15:01, Jakob wrote in "Re: nsec++ ..."]
> or unsigned decimal integers denoting the RR type codes."

yep, you're right,

grtz Miek

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 03 Dec 2003 13:52:23 -0500

Jakob Schlyter wrote:

> please send comments to namedroppers,

I assume this will be folded into the dnssec-records draft, and this 
draft will die.  Assuming this is roughly to replace section 4 of that 
document, I think we've lost some good text about the composition of the 
bitmap(s).  From 4.1.2:

    Each bit in the Type Bit Map field corresponds to an RR type.  Bit 1
    corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
    and so forth. If a bit is set to 1, it indicates that an RRset of
    that type is present for the NSEC RR's owner name. If a bit is set to
    0, it indicates that no RRset of that type present for the NSEC RR's
    owner name.

That is, you've added description of block numbering and bitmap length, 
but lost all description of bitmap construction, and substituted a 
reference to RFC2535.  Moreover, the notion of "window blocks" is never 
explicitly described as corresponding to the upper 8 bits of an RR typecode.

I'd recommend changing para. 2 of 2.1.2, as follows:

    The RR type space is split into 256 window blocks, each
    representing the low-order 8 bits of the 16-bit RR type space.
    Each block that has at least one active RR type is encoded using a
    single octet window number (from 0 to 255), a single octet bitmap
    length (from 1 to 32) indicating the number of octets used for the
    window block's bitmap, and up to 32 octets (256 bits) of bitmap.

    Blocks are present in the NSEC RR data in increasing numerical
    order.

       Type Bit Map(s) Field =

    Each bitmap encodes the low-order 8 bits of RR types within the
    window block, in network bit order.  The first bit is bit 0.  For
    window block 0, bit 1 corresponds to RR type 1 (A), bit 2
    corresponds to RR type 2 (NS), and so forth.  For window block 1,
    bit 1 corresponds to RR type 257, bit 2 to RR type 258.  If a bit is
    set to 1, it indicates that an RRset of that type is present for the
    NSEC RR's owner name.  If a bit is set to 0, it indicates that no
    RRset of that type is present for the NSEC RR's owner name.

    Bits representing pseudo-RR types MUST be set to 0, since they do
    not appear in zone data.  If encountered, they must be ignored
    upon reading.

    Blocks with no types present MUST NOT be included.  Trailing zero
    octets in the bitmap MUST be omitted.  The length of each block's
    bitmap is determined by the type code with the largest numerical
    value, within that block, among the set of RR types present at the
    NSEC RR's owner name.  Trailing zero octets not specified MUST be
    interpretted as zero octets.

This paragraph:

    A zone MUST NOT generate an NSEC RR for any domain name that only
    holds glue records.

Doesn't seem to belong the section describing the type bitmap field.  It 
belongs in Section 2.  It is not related to "wire-format", but to when 
an NSEC RR should exist.

Additional comments:

    - If the TYPE# notation can be used for unknown RR types in a 
symbolic list of RR types, then this should be explicitly mentioned. 
Otherwise, the presense of one unknown type would force the entire set 
to be printed using decimal notation.

    - An example of the actual binary data (octet by octet) for an NSEC 
RR using at least two non-sequential "window blocks" would be useful.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205

---

From: Peter Koch <[email-masked]>
Date: Wed, 03 Dec 2003 20:05:19 +0100

> or unsigned decimal integers denoting the RR type codes."

For the sake of consistency with RFC 3597 I'd use the TYPEnnn convention
and don't see any reason not to allow "mixed" format.

"The Type Bit Map field is represented as a sequence of RR type mnemonics.
 When the mnemonic is not known, the TYPE representation as of section 5
 of [RFC 3597] MUST be used, otherwise it MAY {SHOULD NOT} be used."

Other comments:

2.0
     The NSEC RR is class independent.

   -> The NSEC RR RDATA format is class independent and defined for all
      classes.
     {The RR or the contents of the RR really is class dependent}

2.1.1

   Owner names of RRsets not authoritative for the given zone (such as
   glue records) MUST NOT be listed in the Next Domain Name unless at
   least one authoritative RRset exists at the same owner name.

Isn't this already covered by the reference to canonical sort order?
Anyway, owner names or RRSets are not "authoritative for" the zone
but are "in" the zone (or not). Section 4 of AXFR clarify, which still hasn't
made it to RFC, has some wording about this.

If a discussion is appropriate here, the "empty non-leaf node" problem
could be solved, too. (short: NSEC may point to siblings, children or
parents, but not to nephews).

2.1.2

   Bits representing pseudo-RR types MUST be set to 0, since they do not
   appear in zone data.  If encountered, they must be ignored upon
   reading.

The term "pseudo-RR" needs a definition. Again stealing from 3597 I'd say:

   Bits representing Meta-TYPEs or QTYPEs as specified in [RFC 2929]
   (section 3.1) or within the range reserved for assignment only to
   QTYPEs and Meta-TYPEs MUST be set to 0 ...

This may also change the maximum length calculation a bit (although 2929
doesn't explicitly say that the TYPE reservation is valid for classes
other than IN), which could be provided in an appendix.

-Peter

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 3 Dec 2003 14:32:00 -0500

----- Original Message ----- 
From: "Josh Littlefield" <[email-masked]>
To: "Jakob Schlyter" <[email-masked]>
Cc: "IETF DNSEXT WG" <[email-masked]>
Sent: Wednesday, December 03, 2003 1:52 PM
Subject: Re: nsec++

> document, I think we've lost some good text about the composition of the

(DNSSICbis-editor)
It won't be a full replacement - just some of the RDATA field descriptions.
We'll try to keep much of the descriptive text that is already there (as
long as it is relevant).  That includes the examples.  If you think we need
better (or different) examples, please let the editors know.
(/DNSSECbis-editor)

I like the idea of having a binary format of an example as well.  May help
seeing how the bitmap field looks as "octet value"  "octet value"  "bit
string"  or something besides just the text example.  I could live without
it too.

Scott

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 3 Dec 2003 11:52:37 -0800 (PST)

Some comments on draft-ietf-dnsext-nsec-rdata-00.txt:

> Blocks is presented in increasing numerical order.

Should be "The blocks are...".

> [...]
> zone MUST NOT generate an NSEC RR for any domain name that only
> holds glue records.

These statements are outside the scope of the draft.  The restrictions
described here are not properties of the "DNSSEC NSEC RDATA Format"
but of the DNSSEC protocol; they should be (and presumably already
are) stated in the base DNSSEC protocol specification.

> The Type Bit Map field is represented either as a sequence of RR type
> mnemonics or as a sequence of unsigned decimal integers denoting the
> RR type codes.

I strongly suggest either allowing mixing of mnemonics and integers,
or dropping the integers completely in favor of the TYPE# notation.

The current requirement that the list has to be either all mnemonics
or all integers serves no clear purpose and makes things needlessly
hard on implementations.  Suppose you are printing an NSEC record and
have already printed a couple of mnemonics, and then you come across
an unknown RR type - what should you do, go back and change the
mnemonics you already printed to integers just to satisfy this
requirement?
-- 
Andreas Gustafsson, [email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 21:50:58 +0100

[On 03 Dec, @20:32, Scott wrote in "Re: nsec++ ..."]
> better (or different) examples, please let the editors know.

Will this be in protocol-04? 

grtz Miek

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 3 Dec 2003 15:55:19 -0500

----- Original Message ----- 
From: "Miek Gieben" <[email-masked]>

> Will this be in protocol-04?
The description of the RDATA would be in the Resoure Records draft.  An
example of what an NSEC RR looks like is in the records-05 (section 4.3).  I
would guess any example of a binary (or hex, or any other format) of a
general NSEC RR would go there.

Another example of a signed zone is in protocol-03, but that is for the
example query/responses.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 21:53:48 +0100

[On 03 Dec, @20:52, Andreas wrote in "Re: nsec++ ..."]
> or dropping the integers completely in favor of the TYPE# notation.

I second this, using TYPE# is more consistent with other places where unknown
RRs can exist.

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Dec 2003 22:22:56 +0100

[On 03 Dec, @21:55, Scott wrote in "Re: nsec++ ..."]
> general NSEC RR would go there.

ok :) that's what I wanted to know,

grtz Miek

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Dec 2003 11:50:00 +0100 (CET)

>  of [RFC 3597] MUST be used, otherwise it MAY {SHOULD NOT} be used."

I agree, but do not think we need that last part. suggestion:

     The List of Type Bit Map(s) Field is represented as a sequence of
     RR type mnemonics.  When the mnemonic is not known, the TYPE
     representation as described in RFC 3597 (section 5) MUST be used.

>      {The RR or the contents of the RR really is class dependent}

updated.

> parents, but not to nephews).

as this text was copied from draft-ietf-dnsext-dnssec-records-05.txt, I'd
like comments on this from the editors of that draft before changing
anything.

> other than IN), which could be provided in an appendix.

new text included.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Dec 2003 11:57:14 +0100 (CET)

> are) stated in the base DNSSEC protocol specification.

true, I'll remove this paragraph unless someone objects.

> or dropping the integers completely in favor of the TYPE# notation.

fixed (see my reply to peter koch).

	jakob

-- 
Jakob Schlyter <[email-masked]> +46 70 595 07 94

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Dec 2003 12:30:17 +0100 (CET)

On Wed, 3 Dec 2003, Josh Littlefield wrote:

> [..]

thanks, I think your new text is much more clear - I've incorporated it
with only small changes based on other comments.

> belongs in Section 2.  It is not related to "wire-format", but to when

this paragraph has been removed as it describes protocol, not rdata
format.

> to be printed using decimal notation.

as of RFC3597, there is nothing special about the TYPE# notation. this
paragraph has been updated, see my reply to peter koch.

> RR using at least two non-sequential "window blocks" would be useful.

I'll add this to the 'NSEC RR Example' section.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Dec 2003 15:44:28 +0100 (CET)

> I'll add this to the 'NSEC RR Example' section.

2.3 NSEC RR Example

   The following NSEC RR identifies the RRsets associated with
   alfa.example.com. and identifies the next authoritative name after
   alfa.example.com.

   alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234

   The first four text fields specify the name, TTL, Class, and RR type
   (NSEC).  The entry host.example.com. is the next authoritative name
   after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC
   mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets
   associated with the name alfa.example.com.

   The RDATA section of the NSEC RR above would be encoded as:

         0x04 'h'  'o'  's'  't'
         0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
         0x03 'c'  'o'  'm'  0x00
         0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
         0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
         0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
         0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
         0x00 0x00 0x00 0x00 0x20

   Assuming that the resolver can authenticate this NSEC record, it
   could be used to prove that beta.example.com does not exist, or could
   be used to prove there is no AAAA record associated with
   alfa.example.com.  Authenticated denial of existence is discussed in
   RFC 2535 [2].

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 4 Dec 2003 17:27:52 +0100 (CET)

an updated version of the draft respecifying the rdata format for nsec has
been submitted to the drafts editor and can also be found at the following
address:

    http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-01.txt

	jakob