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

From: Samuel Weiler <[email-masked]>
Date: Tue, 23 Mar 2010 17:59:15 -0400 (EDT)

During today's meeting, MSJ asked what happened to this.  As doc 
editor, I apologize for not catching this explicitly during this 
revision cycle, but (editor hat off) I don't entirely agree with the 
recommendations below.

On Thu, 15 Jan 2009, Michael StJohns wrote:

> "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 new text gives resolvers permission to set CD, but does not 
require them to set it.

And I see a reason for not setting it: unsigned holes in the tree. 
Imagine that the root is signed, a TLD isn't, and some second level 
domains are signed.  You are contemplating installing a trust anchor 
for the root.  With MSJ's proposed rules, installing the root trust 
anchor means you lose any protection offered by an upstream resolver, 
which might have some trust anchors installed for those second level 
domains.  (Perhaps because its admins are willing to do the work of 
maintaining a large pile of trust anchors, whereas you're only willing 
to maintain the one trust anchor for the root.)

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

As you know, the current version of the doc says something very 
different.

The current working is based on the expectation that the only form of 
"suffering from the cache" you'll see is a full SERVFAIL. 
Specifically, data is never partially suppressed.  Is there some other 
form of suffering which would justify doing the extra work of 
requerying every time?

-- Sam

---

From: Michael StJohns <[email-masked]>
Date: Wed, 24 Mar 2010 02:59:24 -0400

At 05:59 PM 3/23/2010, Samuel Weiler wrote:
>During today's meeting, MSJ asked what happened to this.  As doc editor, I apologize for not catching this explicitly during this revision cycle, but (editor hat off) I don't entirely agree with the recommendations below.
>
>>"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 new text gives resolvers permission to set CD, but does not require them to set it.
>
>And I see a reason for not setting it: unsigned holes in the tree. Imagine that the root is signed, a TLD isn't, and some second level domains are signed.  You are contemplating installing a trust anchor for the root.  With MSJ's proposed rules, installing the root trust anchor means you lose any protection offered by an upstream resolver, which might have some trust anchors installed for those second level domains.  (Perhaps because its admins are willing to do the work of maintaining a large pile of trust anchors, whereas you're only willing to maintain the one trust anchor for the root.)

This is an interesting but somewhat contrived example - and the first time I recall it being brought up.  I see your point, but then I ask - what is the operational model you would use for an intermediate resolver closest to the client?  How would you decide whether or not to set the CD bit - would you do it per query, or based on a configuration parameter or do it randomly or what?

If your local resolver has a trust anchor for root and no other, then you have to assume that your local resolver has accepted responsibility for validating the entire tree.  Or do you want to add language that allows the local resolver to *configure* exceptions to the above rule? I'm not opposed to this, but it needs to be expressed as a configuration parameter, and not simply permission to *implement* a varying strategy. But that is not what the current language says as I read it. If you simply want to say that the resolver can do what it wants - I'm staunchly opposed as it prevents even the possibility of coherence.  Pick a default, pick a way to deal with the corner cases and have done.  Leaving this as an exercise for the implementer is not useful.

E.g.:

"If the validating recursive resolver has a trust anchor covering a request, it MUST by default set the CD bit on its upstream query regardless of the CD bit setting of the request. A resolver MAY implement a mechanism to exempt by name queries otherwise covered by this rule.  E.g. if the resolver has a trust anchor for FOO.COM, it may also have an exemption for BAR.FOO.COM and its subsidiary nodes to allow an upstream resolver to do the validation for those queries if any validation is possible."

Rationale: The setting of the trust anchor is an implied contract that the local resolver is responsible for all validations covered by that trust anchor absent any statement to the contrary.

>>"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."
>
>As you know, the current version of the doc says something very different.
>
>The current working is based on the expectation that the only form of "suffering from the cache" you'll see is a full SERVFAIL. Specifically, data is never partially suppressed.  Is there some other form of suffering which would justify doing the extra work of requerying every time?
>
>-- Sam

Reviewing the bidding, the language *is* wrong.  It probably should be something like:

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

Rationale: if the cache is "poisoned" with the raw data by a query setting the CD bit you need to repeat the query with the CD bit cleared to get the upstream validated response which may be the same data, or could be a SERVFAIL etc.  And this is contingent on whether the local resolver has a trust anchor for the query.  The current language is correct about queries resolved with the CD bit not set, but misses the dual.

I'm doing a decision flow chart - I'm finding it complex - mainly because of caching. Give me a day or so to work through the logic.  

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 24 Mar 2010 03:51:37 -0400

Attached is a first cut at the processing diagram.

Note that non-validating resolvers get treated as if they are validating resolvers that have no configured trust anchors - because of caching issues.

The definition of "covering trust anchor" is as described in the discussion below.  e.g. a name is covered if it has a covering trust anchor and has no covering exception.

Feel free to mark this up and repost.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Wed, 31 Mar 2010 22:50:40 -0400

This appears to have black-holed yet again.   Could we please work this through to a valid and supportable conclusion?  The language in -11 is wrong.

Mike

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 31 Mar 2010 22:58:44 -0400 (EDT)

On Wed, 31 Mar 2010, Michael StJohns wrote:

> This appears to have black-holed yet again.  Could we please work 
> this through to a valid and supportable conclusion?  The language in 
> -11 is wrong.

It's not black-holed, I just didn't delve into it in depth during the 
meeting week.  Both this and the rollover-and-die fixes need work.
Would you feel better if we pushed a -12 saying "this section is still 
broken"?

-- Sam