Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 03 Feb 2009 12:23:33 +0100

Michael StJohns wrote:
> At 02:59 PM 1/16/2009, David Blacka wrote:
>> Or to put this another way, how does CD change a response?  If it does  
>> anything, it changes a DNSSEC response to a SERVFAIL, which isn't  
>> cached.
> 
> This is the point that I keep trying to forget about DNSSEC - and I think I succeeded too well this time.  David is absolutely correct. :-)  Delete anything I said about setting the CD bit in response to what's in cache.

OK

>> I do think that the dnssec-bis-updates draft section 4.7 could say:
>>
>>   When processing a request with the CD bit set, the resolver MUST set
>>   the CD bit on its upstream queries.
>>
>>   Furthermore, if the validating recursive resolver has a trust  
>> anchor covering a request, it
>>   SHOULD set the CD bit on its upstream query regardless of the CD  
>> bit setting of the request.
> 
> MUST or SHOULD here?  I think if you've configured a trust anchor you've accepted responsibility to resolve according to local policy so I'd put this as a MUST.
> 
> I can't think of a reasonable reason why you would set a trust anchor and not set the CD bit in the upstream.  [OK - I can think of an unreasonable reason - local resolver has .COM trust anchor, upstream resolver has FOO.COM trust anchor, but not .COM - upstream filters FOO.COM if data is bad but passes through the rest of .COM.  I don't think this makes a lot of sense though - the local resolver doesn't necessarily have a clue what trust anchors are configured in the upstream resolver so it can't really make a decent decision on whether to set/not set the CD bit. The local resolver would have to know that the upstream resolver has a FOO.COM trust anchor and to not set the bit for those queries - seems complicated ]
> 
> I can live with the text as above, and will bow to the consensus with respect to MUST or SHOULD.

I can live with the text too.

For SHOULD or MUST - I can imagine deployment where servers do not set
upstream CD bit because the operator wants simple caches to forward
queries towards a validating server (that has all the keys) - and thus
SHOULD.   If you need explanatory text: 'If so configured, a recursive
resolver could opt to not set the CD bit to allow upstream validation'.
 I do not think this explanatory text is needed (for dnssec-bis updates).

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 11 Feb 2009 09:40:27 -0500

At 06:23 AM 2/3/2009, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Michael StJohns wrote:

I still don't really care about must v should here, but I don't think this argument holds water.  If you want the upstream resolver to do all the validation, all you have to do is delete all the trust anchors at the intermediate resolver.

So is there a *real* case where the intermediate resolver has a trust anchor for some.zone where you wouldn't set the CD bit for a query to example.what.who.some.zone?   I think for the purposes of this discussion, you can't make any assumptions about trust anchors for any upstream resolver...you can't even make assumptions about who will answer the query a priori.

Mike