Subject: RE: Protection of unsecured delegations

From: "Larson, Matt" <[email-masked]>
Date: Fri, 21 Dec 2001 10:11:48 -0500

Hi, Bill.

> I think there needs to be more text on resolver behavior, and, in
> particular, a discussion of resolver search paths.
> 
> I can see resolvers doing any of:
> 
> [a] Do the lookup and only return trusted data.  Not useful to me
> until everyone I care about has opted in..
> 
> [b] If there's trusted data anywhere on the path, return the first
> trusted answer, otherwise return the first non-trusted answer.
> 
> [c] Return the first name along the path for which a query returns
> some data.

Maybe I'm the only one, but I'm sorry, I don't understand your [b] or [c].

For [b], what do you mean "return the first trusted answer" and "first
non-trusted answer"?  I don't understand "first" in this context.

For [c], what do you mean by "first name along the path for which a query
returns some data"?  Do you mean "return the last name of the last secure
zone encountered while descending the name space looking for the quered
name"?  In terms of what's useful to an application and/or stub resolver
(IMHO), a queried <name, type, class> either exists or it doesn't.  If it
exists, it's either signed or it isn't.

Matt

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Dec 2001 10:34:05 -0800

> non-trusted answer"?  I don't understand "first" in this context.

see the "search" directive of /etc/resolv.conf.

bill's examples are the first i've seen of how common applications will
benefit from dnssec.  counter proposals should look like API specifications.