This is a discussion on Re: additions to dnssec-bis-updates-04.txt - DNS ; Edward Lewis wrote on 12/19/2006 05:11:42 PM: > 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 ...
wrote on 12/19/2006 05:11:42 PM:
> At 16:43 +0100 12/19/06, Roy Arends wrote:
> >As promised (though a little late) here are my quirks from the
> >presentation on DNSSEC-bis omissions:
> Dallas? Or Montreal? Or San Diego?
> >One rant on DNSSEC-bis is that it groups empty-non-terminal response
> >as "name errors" instead of "no data errors" (section 220.127.116.11 of RFC
> >4035). I think it was Rob Austein who explained during the WG session
> >the term "Name Error" used in DNSSEC-bis does not necessarily reflect
> >"rcode=3 (name error)". In hindsight, this is purism, and does not
> >any holes in the validation logic. This is not all that important, so
> >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
> 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'
> >NSEC Origin checks. For every existing name (except for the empty
> >label/root), there exists a spanning NSEC in an ancestor zone. Not just
> >the parent zone. So the following rule for the type-bit-map must be
> >for proof of absence of name check when NSEC ownername is an ancestor
> >the QNAME: (NOT DNAME) AND ((NOT NS) OR SOA). My guess is that you
> >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.
This was exactly my point.
> 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?)
No, you're not.
You want to be sure the NSEC record is from the correct zone, lets say
"from the zone that has the authority to make that claim", and not from an
I was ranting against the use of the word 'parent' instead of ancestor.
that is all.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.