Re: IESG feedback on dnsext-ad-is-secure

["Eric A. Hall" <ehall@ehsco.com>]

on 6/12/2002 1:37 AM Robert Elz wrote:

> Note that the back end resolver (the one that received Rd=1, has RA=1,
> and actually sets the AD bit) has no method to know what kind of
> resolver is talking to it - it doesn't know whether the back end trusts
> it or not (it may know that it is going to use TSIG to communicate with
> its client, but presence of TSIG does not guarantee trust, nor does its
> absence prohibit it), so it just sets the AD bit (or doesn't) on all
> queries it processes, regardless of whether the value will end up being
> used or not.

First a disclaimer that I haven't fully internalized all of the DNSSEC
stuff so this has the potential to be a really stupid question.

It seems to me that there are a couple of problems that can be solved by
providing a way for the stub resolver to indicate whether or not the
calling application and/or the stub resolver is going to perform
validation, at which point there is only a question of how this desire
should be signalled.

I would think that using a flag in a psuedo OPT RR would handle this
nicely. On the one hand this tells the back-end resolver what kind of data
it needs to return (if the calling application or stub resolver is opaque
about DNSSEC then it only has to return the normal stuff). Secondarily,
the use of the OPT RR tells the back-end resolver that the stub resolver
is capable of accepting large messages containing all of the crap that the
stub and/or application needs. Would this work?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/


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