Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

In message <alpine.BSF.2.00.1204301341240.95708@fledge.watson.org>, Samuel Weiler writes:
> On Mon, 12 Mar 2012, Samuel Weiler wrote:
> 
> > On Fri, 20 Jan 2012, Edward Lewis wrote:
> ...
> >> 5.9's title is misleading.  The content is good, it's about answering from 
> >> cache in the face of a CD query.  But "always doing CD" only applies to 
> >> elements that will do their own validation.
> >
> > Doesn't it also apply to a non-validating box in the middle?  That box may 
> > still need to return +CD data if something downstream wants it.
> >
> > The only place I see it not applying is stub resolvers.  Rather than alter 
> > the title (since I couldn't think of a good way to do it), I propose adding a 
> > paragraph saying "this doesn't apply to stub resolvers".
> 
> During his PROTO review, Andrew observed that the CD bit appendix 
> mentions validating stub resolvers and, indeed, it seems to me that 
> section 5.9 would apply to validating stub resolvers also.  At least 
> for the moment, I've removed the sentence saying the section doesn't 
> apply to stub resolvers.  If there's a better way to fix this, please 
> speak up.

The advice to always set +CD is just *bad*.  If you are talking
*directly* to the authoritative servers it doesn't hurt.  If you
are talking through another recursive server it leaves the client
unable to get at good data when bad data is being presented to the
recursive server.  All element of the resolution path SHOULD be
validating responses.

> -- Sam
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext