Re: comments on draft-ietf-dnsext-dnssec-bis-updates-05

[Michael StJohns <mstjohns@comcast.net>]

4035 doesn't say what I think you think it says... 

It says that the Nameserver side passes the bit to the resolver side so that the resolver side will return the records it has without checking.  It doesn't say that the resolver side should set the bit in its upstream queries  - I can't read this section in a way that would constitute an implicit indication this bit should be set.  

 As written, if the next upstream resolver is also a validating resolver, it will filter out "bad" data even if the CD bit is set, so the client will never see the raw data.

E.g.  

client -> intermediate resolver (local cache) -> intermediate resolver (provider cache or forced proxy) -> zone server

If the local cache resolver doesn't set the bit, the provider cache resolver won't return the raw stuff.

Suggest actually stating this explicitly along the lines of:

"The resolver side of a security-aware recursive resolver MUST set the CD bit on its upstream queries."

I wrote the above as an all the time thing - i'm pretty sure a security aware recursive server should ALWAYS be getting the raw stuff without filtering.  Otherwise the cache could be incorrect if the first query to a record is without the CD bit and the signature stuff is wrong.

Mike



At 23:20 11/18/2007, Sam Weiler wrote:
>On Thu, 8 Mar 2007, Scott Rose wrote:
>
>>I just (quickly) read over the -05 version of the DNSSEC-bis-updates draft. I noticed 2 typos and 1 issue that may have been resolved, but I can't remember.   [typos snipped]
>
>Thank you for catching these.  The newest version of the draft fixes both typos.
>
>>Also, I remember on thing from MSJ's DNSSEC-SO draft:  In section 2.3.2.2, third bullet item (in regards to recursive caching servers):
>>
>>     The resolver side MUST also set the CD bit when sending queries
>>     when the CD bit is set in the initiating query.  [Note: The
>>     current behavior for a PNE recursive resolver may be in error.]
>>
>>Has this been covered in a thread?  I don't remember.  In my mind, it may be necessary if there is some upstream cache in the middle.  The caching resolver still has the option (local policy) to perform validation after sending the response back to the originator for determining the cache status (BAD or not).
>
>I don't remember a thread on this, but I think RFC4035 already says this (implicitly) in the third paragraph of section 3.2.2: http://tools.ietf.org/html/rfc4035#section-3.2.2
>
>Am I misunderstanding this?  Do we need to clarify it further?  (I'm CC'ing MSJ in case he might have some wisdom to offer.)
>
>-- Sam (dnssec-bis-updates co-editor)



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