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

From: Michael StJohns <[email-masked]>
Date: Thu, 15 Jan 2009 13:52:05 -0500

Why was the text on the upstream setting of the CD bit left out of yet another revision of this document?

C.f. Name Droppers 9/15/2008, Proposed addition to dnssec-bis-updated: CD bit, Namedroppers 3/11/2008 CD bit setting from intermediate resolvers...., Namedroppers   - discussions at dnsext.  Etc...

Mike

--
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: "Blacka, David" <[email-masked]>
Date: Thu, 15 Jan 2009 14:26:50 -0500

> yet another revision of this document?

I thought it was included.  Isn't your concern addressed by section  
4.7?  Or did I miss something?

>
> C.f. Name Droppers 9/15/2008, Proposed addition to dnssec-bis- 
> updated: CD bit, Namedroppers 3/11/2008 CD bit setting from  
> intermediate resolvers...., Namedroppers   - discussions at dnsext.   
> Etc...
>
> Mike
>
>
>
> --

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Michael StJohns <[email-masked]>
Date: Thu, 15 Jan 2009 15:03:47 -0500

>4.7?  Or did I miss something?

This got one of them.  The other is the proper setting of CD bits from a validating resolver:

"If the validating recursive resolver has a trust anchor covering a request, it MUST set the CD bit on its upstream query regardless of the CD bit setting of the request.

If the validating resolver has DLV configured to cover a request, it MUST first resolve the DLV query to determine whether the request is covered by a DLV trust anchor.  If the request IS covered by a validated DLV trust anchor, the resolver MUST set the CD bit on its upstream query."

The first of these ensures that the validating resolver gets to make up its own mind about validity.  The second ensures we have the right setting of "should be signed" before proceeding.  The exact ordering may need a little tweaking.

And the language needs to ensure that the CD bit stuff doesn't suffer from the cache:

"If the recursive resolver receives a request with the CD bit set and has previously cached data covered by that request and retrieved without setting the CD bit, it MUST repeat the upstream query with the CD bit set."

Thanks - Mike

>>C.f. Name Droppers 9/15/2008, Proposed addition to dnssec-bis- updated: CD bit, Namedroppers 3/11/2008 CD bit setting from

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 16 Jan 2009 09:25:52 +0100

Hi Michael,

I disagree strongly with your text.  The problem lies not in explaining
how to use the CD bit, which is a laudable goal.  The problem lies in
you forcing particular resolution order on resolvers.

Proposed text:
The recursive resolver SHOULD answer queries with the CD bit set with
information obtained using upstream queries made with the CD bit set.

If the recursive resolver does not trust the security policy from
upstream resolvers, it SHOULD validate based on upstream queries made
with the CD bit set.

Best regards,
   Wouter

---

From: David Blacka <[email-masked]>
Date: Fri, 16 Jan 2009 14:59:47 -0500

On Jan 16, 2009, at 3:25 AM, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
>

So, I was arguing with MSJ about this off-list.  My contention is that  
CD doesn't affect the cache in any meaningful way, so it doesn't  
matter if the recursive resolver got the response from the +CD or -CD  
bit query.

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.

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.

But other suggestions are welcome.

--
David Blacka                          <[email-masked]>
Sr. Engineer          VeriSign Platform Product Development

---

From: Michael StJohns <[email-masked]>
Date: Sat, 17 Jan 2009 03:16:00 -0500

>anything, it changes a DNSSEC response to a SERVFAIL, which isn't  

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.

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

Mike