At 19:52 +0100 12/19/06, Roy Arends wrote:
>Edward Lewis 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 from

>an
>> >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 ... edu

with 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: