[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: additions to dnssec-bis-updates-04.txt



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 3.1.3.2 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 matters.

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 domains).

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
NeuStar

Dessert - aka Service Pack 1 for lunch.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>