On Mar 27, 2006, at 2:52 PM, Sam Weiler wrote:

> On Mon, 27 Mar 2006, Olaf M. Kolkman wrote:
>
>>> I.e., by issuing a query for possible-delegation/IN/NS to the
>>> parent.

>>
>> Would querying for a DS at that parent work? I would think that
>> that would be the regular fall back when trying to build a chain
>> of trust?

>
> I'm not certain, but it could only work if you either were lucky
> enough to guess the proper name of the delegation point or tried
> them all (remembering that the parent could have a multi-label
> delegation). This is one of the reasons why the underspecification
> in 4.2.1 worries me.


The issue here isn't that you would have to guess the name of the
delegation point. In normal 4035 DNSSEC, you would have to try them
all, or at least, try them until you got an actual insecure delegation.

The issue is that the response to the DS query doesn't really tell
you if that name has a delegation or not. That is, the response
looks the same if there is a delegation or just some other insecure
RRSet.

However, in general, I think that this is OK, even if it doesn't
comply with the MUST in 4.2.1 of opt-in. I think this because, while
it would allow some forms of non-delegation-only zones to actually
work (assuming the authoritative nameserver knew how to serve it
correctly), it wouldn't expose new corner-cases in the zone itself
(such as: can the SOA be opted-out? can a wildcard?)

>
> FWIW, I do concur with David's statement: "I don't see any actual
> security value from the validator actually enforcing delegation-
> only", which is one of the reasons I advocated removing the
> delegation-only restriction rather than add more complexity to the
> validator and the document.


--
David Blacka
Sr. Engineer VeriSign Applied Research




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