This is a discussion on Re: additions to dnssec-bis-updates-04.txt - DNS ; At 16:43 +0100 12/19/06, Roy Arends wrote: >As promised (though a little late) here are my quirks from the dallas-ietf >presentation on DNSSEC-bis omissions: Dallas? Or Montreal? Or San Diego? >One rant on DNSSEC-bis is that it groups empty-non-terminal response ...
At 16:43 +0100 12/19/06, Roy Arends wrote:
>As promised (though a little late) here are my quirks from the dallas-ietf
>presentation on DNSSEC-bis omissions:
Dallas? Or Montreal? Or San Diego?
>One rant on DNSSEC-bis is that it groups empty-non-terminal response types
>as "name errors" instead of "no data errors" (section 126.96.36.199 of RFC
>4035). I think it was Rob Austein who explained during the WG session that
>the term "Name Error" used in DNSSEC-bis does not necessarily reflect
>"rcode=3 (name error)". In hindsight, this is purism, and does not create
>any holes in the validation logic. This is not all that important, so my
>suggestion here is to remove the following part in dnssec-bis-updates:
I don't think redefining terms in this way is just a violation of purism.
I can't think back 3 IETF's though to recall the conversation.
>(1) ancestor versus parent terminology
>I'd suggest avoiding 'parent-side' terminology in favor of 'ancestor' for
>NSEC Origin checks. For every existing name (except for the empty
>label/root), there exists a spanning NSEC in an ancestor zone. Not just at
>the parent zone. So the following rule for the type-bit-map must be true
>for proof of absence of name check when NSEC ownername is an ancestor of
>the QNAME: (NOT DNAME) AND ((NOT NS) OR SOA). My guess is that you wanted
>to state this in section 2.1 of the update document, but that needs to
>rewritten. This is somewhat a purity issue, since the validator can't
>distinguish parent from grandparent or further ancestors.
This is only an issue when you are staring at two NSEC sets/records
owned by the same name. In this case, it is just the parent that
E.g., for www.foo.bar.example.com, assuming all zones are just one
label deep, yes, you have a lot of NSECs covering the name. Assuming
that www.foo.bar.example.com is not a delegated point, then all of
the NSEC's will have different owner names (and signed by different
If www.foo.bar.example.com is delegated from example.com, then there
will be two NSEC's, both owned by www.foo.bar.example.com. You can
distinguish which is which by the bitmap.
A domain name will not own records in more than two zones, ever. If
there are records in two zones, it is parent and child we are seeing.
(Am I missing a point here?)
Edward Lewis +1-571-434-5468
Dessert - aka Service Pack 1 for lunch.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.