Subject: [dnsext] Re: Proposed addition to dnssec-bis-updated: CD bit

From: Peter Koch <[email-masked]>
Date: Mon, 15 Sep 2008 11:31:18 +0200

On Wed, Jul 30, 2008 at 09:42:50PM +0100, Blacka, David wrote:

> 3.7.  Setting the CD bit on Requests
> 
>    When processing a request with the CD bit set, the resolver MUST set
>    the CD bit on its upstream queries.

part of my confusion originates from the term "upstream queries". When the
recursive resolver is iteratively resolving a query, it talks to - allegedly -
authoritative servers.  These queries will traditionally have RD=0.
Not sure the CD bit makes much sense here, except that there are some
configurations possible (but maybe undesirable) where an authoritative
server would fetch additional information that could or could not be
validated.
When "upstream queries" refers to environments with multiple levels of
"forwarders" instead, the proposed text would extend the "CD" semantics
from hop-by-hop to "end-2-end".  What's the rationale behind that?

-Peter

--
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: [email-masked]
Date: Mon, 15 Sep 2008 11:00:19 +0100

> from hop-by-hop to "end-2-end".  What's the rationale behind that?

Another possible clarification issue needed with CD=1 is that there is a 
perception that it means that the "upstream" resolver MUST NOT validate at 
all.

However my research shows that Bind (and ISTR unbound too) will return the 
cached result of previous successful validations in the AD bit when CD=1.

Ray

---

From: Florian Weimer <[email-masked]>
Date: Mon, 15 Sep 2008 16:21:35 +0200

> perception that it means that the "upstream" resolver MUST NOT validate at 

Is it possible to implement this without a fully separate cache for
CD=1 mode?

Can CD=1 be deprecated, with a recommendation to use it as a debugging
tool only?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: [email-masked]
Date: Mon, 15 Sep 2008 15:34:14 +0100

> Is it possible to implement this without a fully separate cache for

I'd rather see a clarification.
 
> Can CD=1 be deprecated, with a recommendation to use it as a debugging

No, it's needed if you want to do desktop DNSSEC validation and not rely 
on your upstream.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Sep 2008 14:39:25 +0000

> Can CD=1 be deprecated, with a recommendation to use it as a debugging

makes sense to me.

---

From: Rob Austein <[email-masked]>
Date: Mon, 15 Sep 2008 11:39:28 -0400

> Can CD=1 be deprecated, with a recommendation to use it as a debugging

No.  Without CD=1 you have no way of determining whether the local
recursive name server (eg, in a hotel, where you have no choice about
using it) is lying to you, and there's no way to write a validating
stub resolver.

DNSSEC is an end-to-end validation mechanism with a nasty backwards
compability kludge in the middle: without CD=1, recursive nameservers
become validating middleboxes, to protect DNSSEC-oblivious clients.
CD=1 is required to enable the end-to-end validation model for
applications that are smart enough to use it.

---

From: Rob Austein <[email-masked]>
Date: Mon, 15 Sep 2008 11:47:01 -0400

> perception that it means that the "upstream" resolver MUST NOT validate at 

It's allowed to validate, just not to impose its opinion on the
client.

> cached result of previous successful validations in the AD bit when CD=1.

See RFC 4035 3.2.2.  The specific wording is:

   If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.  That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.

Some explanation of the rationale appears a bit later in that section:

   The intent of the above rule is to provide the raw data to clients
   that are capable of performing their own signature verification
   checks while protecting clients that depend on the resolver side of a
   security-aware recursive name server to perform such checks.  Several
   of the possible reasons why signature validation might fail involve
   conditions that may not apply equally to the recursive name server
   and the client that invoked it.  For example, the recursive name
   server's clock may be set incorrectly, or the client may have
   knowledge of a relevant island of security that the recursive name
   server does not share.  In such cases, "protecting" a client that is
   capable of performing its own signature validation from ever seeing
   the "bad" data does not help the client.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Sep 2008 16:06:09 +0000

> applications that are smart enough to use it.

for the record, i stand corrected, i had agreed with the first-quoted text.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Sep 2008 09:58:23 +1000

> using it) is lying to you, and there's no way to write a validating

	DO=1 is that signal.  CD=1 allow you to get answers that
	could potentially fail validation by the upstream server
	due to a bad clock or out of date trust anchors.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Sep 2008 20:44:36 -0400

Sorry I missed this when it first came out.. this is a response post-reading what was posted on 15 Sept.

There are two cases here that are not currently covered by language in the standard:

The first is the case in which the query to the validating resolver came in with the CD bit set.  In this case, the language you propose is reasonable (set the CD bit in the upstream).

The other case is when the query to the resolver comes in with the CD bit cleared, but where the resolver has a configured trust anchor covering the query.  E.g. I query the comcast resolver for something in .COM somewhere else.  The comcast resolver has a trust anchor for .COM and so has been configured to validate .COM.  In this case, shouldn't the comcast resolver set the CD bit for any attempt to resolve .COM?  Don't you want to prevent any upstream resolver from filtering .COM responses?

Mike

At 04:42 PM 7/30/2008, Blacka, David wrote:
>Folks,
>
>Here is another bit for the dnssec-bis-updates draft that appears to  
>have fallen through the cracks.  It is unclear, however, that this  
>addition has any sort of consensus, so a positive acknowledgement that  
>this text is OK would be nice.  Here is the proposed addition:
>
>Any comments?
>David Blacka                          <[email-masked]>
>Sr. Engineer                   Platform Product Development
>
>
>--

---

From: Michael StJohns <[email-masked]>
Date: Mon, 15 Sep 2008 20:54:35 -0400

At 05:31 AM 9/15/2008, Peter Koch wrote:
> When the
>authoritative servers.  

That's the problem with the current definition, the definitions assume the client->recursive resolver->authoritative server  model and that's not always the case.  I know of a few environments that are client->forwarding resolver->recursive resolver->authoritative server and I've heard of plans for one environment with at least one more intermediate step.

>from hop-by-hop to "end-2-end".  What's the rationale behind that?

The rationale is that the validator, where ever it may be, needs to get the source material, and not that filtered by intermediate validators.  If the client is a validating client, then the CD bit tells the first upstream not to filter.  What you want to do is tell the second and third upstreams not to filter as well if they exist and that can't be done without enforcing behavior on the intermediate resolvers.

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Sep 2008 11:48:23 -0400

At Mon, 15 Sep 2008 20:54:35 -0400, Michael StJohns wrote:
> 
> That's the problem with the current definition, the definitions
> assume the client->recursive resolver->authoritative server model

That was not the editors' intent.  Where do you see that assumption in
RFC 4035 3.2.2?  Note that "resolver" without further qualification
means any resolver, including the resolver side of a recursive name
server; if we'd meant "stub resolver", we would have said so.

> and that's not always the case.

Right, and the definition doesn't assume that.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 16 Sep 2008 21:06:55 -0400

>> assume the client->recursive resolver->authoritative server model

Sorry about that... I'm imputing meaning to missing text... what I really meant was that there was no explicit calling out of a model different from the client (recursive resolver) -> authoritative server or client (stub) -> recursive server -> authoritative  server models in the document.  A model where there are more than one intermediates between the client stub resolver and the authoritative server really wasn't in any of the editor's minds as far as I can tell from the text.  If that is an incorrect assumption, I apologize - I couldn't find text to cover it one way or the other.

For normal DNS, this isn't a big issue, because all the upstream resolvers will either return the data they have or do a referral.  DNSSEC makes this a lot more complicated. (my understatement for the day.. :-) )

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Sep 2008 21:44:50 -0400

At Tue, 16 Sep 2008 21:06:55 -0400, Michael StJohns wrote:
> 
> Sorry about that... I'm imputing meaning to missing text... what I
> really meant was that there was no explicit calling out of a model
> different from the client (recursive resolver) -> authoritative
> server or client (stub) -> recursive server -> authoritative server
> models in the document.  A model where there are more than one
> intermediates between the client stub resolver and the authoritative
> server really wasn't in any of the editor's minds as far as I can
> tell from the text.  If that is an incorrect assumption, I apologize
> - I couldn't find text to cover it one way or the other.

Incorrect assumption, at least in my case.  Strunk strikes again.