At 19:52 +0100 12/19/06, Roy Arends wrote:
Edward Lewis <Ed.Lewis@neustar.biz> wrote on 12/19/2006 06:14:26 PM:At 17:38 +0100 12/19/06, Roy Arends wrote: >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 froman>ancestor zone. The only time the bit map will give a hint whether the NSEC is right or not is when it is parent/child involved, when the owner name is the same between two NSEC choices.root: com NSEC edu NS DS tld: example.com NSEC lewis.com NS DS sld: www.example.com NSEC example.com A QNAME is www.example.com The spoofed response contains: com NSEC edu NS DS This is obviously from an ancestor (grandpa in this case), not the parent. This was about terminology, not the rules itself, so I don't see what the rest of your response about rules and ways to check, etc, etc has to do with my point about terminology.
What's the point about terminology? The doc, in 2.1, talks about distinguishing between parent-side and child-side NSEC through the use of the bit map. This same check is unique to the parent-child issue, it isn't pertinent to any zone up the tree (toward the root).
In your example, I don't see this working. "com NSEC edu NS DS" doesn't indicate a span from com to edu, it covers the span from the last name in the com *domain* (not zone) to edu. I see this:
com ... www.example.com .... lastnamein.com ... eduwith the NSEC saying there is nothing after lastnamein.com until you get back to edu. The NS bit says this. So the NSEC is not covering the QNAME.
In 2.1, the words there are about the problem of having this:
example.com NSEC foobar.com NS DS DNSKEY RRSIG NSEC
example.com NSEC a.examppe.com SOA NS DNSKEY RRSIG NSEC
Are you saying that there's a missing case of mistaken identity -
that we need to be clear that a NSEC with an NS or DNAME bit means
the span is from the end of the owning domain? Truthfully, the span
is always from the end of the owning domain - the NS bit just reminds
us that there are names lower in the tree, that the owning domain is
not terminal.
I think that 2.1 is accurate - any parent-side NSEC can be misused (via misinterpretation) to deny data below it, the section doesn't limit the damage to only the zone below.
Looking upwards, it isn't just the parent-side NSEC whose bitmap matters. But 2.1 doesn't say to only look up to the parent-side NSEC, as opposed to the ancestor.
OTOH, 2.1 isn't exactly clear..."both RRs at that ownername and at ownernames with more leading labels, no matter their content" I don't understand the point of that comment.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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/>