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

From: Samuel Weiler <[email-masked]>
Date: Mon, 30 Apr 2012 13:43:37 -0400 (EDT)

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.

-- Sam

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 May 2012 11:26:41 +1000

> apply to stub resolvers.  If there's a better way to fix this, please 

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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext