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

[Michael StJohns <mstjohns@comcast.net>]

OK - thinking about it, I think its even more complex than this.  I think the CD bit gets set in only those upstream queries where the resolver has a configured trust anchor superior to the query.  (.e.g .COM for queries to sub1.example.com)

Let's say your local validating resolver has a trust anchor for "example.com" but not ".com"  Let's say the next upstream resolver has a trust anchor for .com.   If the local resolver sets the CD bit on queries in foo.com the client could get data in foo.com even if the data were invalid at the upstream resolver even though the upstream resolver should have protected the local resolver.



The next question is how does this interoperate with DLV?  The DLV covered zone (e.g. a dlv server for .com) isn't trust anchor for .com, but contains a set of trust anchors within .com.  If your local resolver has a set of DLV covered zones ... do you wait to figure out how to set the CD bit until after you query for DLV resolution?

My head hurts.

Any thoughts?



At 23:56 11/18/2007, Michael StJohns wrote:

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



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