Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Jun 2010 17:22:13 -0400

I've turned back to this today, in an effort to nail down what it is
the draft is going to say.

On Wed, May 19, 2010 at 11:39:33AM -0400, Michael StJohns wrote:
> 
> "Security aware intermediate resolvers MUST set the CD bit on any
> upstream query for which they have a covering trust anchor (TA) or
> for which the downstream query has the CD bit set."

The counter-arguments for this have been made, and amply in my
opinion.  The text already suggests that for most cases, it's better
just to set it and move on:

   For efficiency, a validator may wish to set the CD bit on all
   upstream queries when it has a trust anchor at or above the QNAME
   (and thus can reasonably expect to be able to validate the
   response).

If you want something stronger than that, then maybe another sentence
can be added suggesting that not doing so could increase the chances
of failure.  But several people have argued that the MUST is too
prescriptive, because they have a plan for how to use the protocol
under circumstances where they want not to set CD as you seem to want
them to.  Even if you think it's a bad idea, it would appear we're
not going to get consensus on anything as strong as MUST here.
 
> Security aware intermediate resolvers SHOULD cache data returned
> from an upstream (server side) query which had the CD bit set.  If
> the downstream (client side) query also has the CD bit set, the
> resolver MAY defer validation of this data (assuming a covering TA)
> until a later non-CD bit query for the same data, but MUST mark the
> cached data as non-validated until local validation actually occurs.

I'm not sure whether the first sentence is meant to imply that the
intermediate resolver shouldn't cache CD=0 data, but I presume not.
How about this:

    When caching, a security-aware intermediate resolver MAY return
    data without validating it only if the original query had the CD
    bit set.  In that case, the intermediate resolver MAY defer
    validation of the data, but MUST mark the cached data as
    non-validated until local validation actually occurs.  It MUST NOT
    return the cached, unvalidated data to a query with CD=0.  

?
 
> Security aware intermediate resolvers SHOULD cache SERVFAIL
> responses returned from an upstream query. They MUST cache the state
> of the CD bit in all upstream queries as well.  If a security aware
> intermediate resolver receives a CD bit set query for data which has
> a SERVFAIL cached, the resolver MUST set the CD bit on the upstream
> query and SHOULD cache BOTH the SERVFAIL and the data returned on
> the CD bit set upstream query.

As I read that paragraphm it says that the intermediate resolver gets
a query with CD=1, for data for which it has SERVFAIL.  The resolver
side now queries again with CD=1, and gets that answer.  Then it has
two cache entries: one for QNAME, CD=0 (SERVFAIL) and one for QNAME,
CD-1.  Is that what you intend?  Why can't it throw away its CD=1
result and just not cache that?

> Data in cache with the CD bit set which has not been locally
> validated MUST NOT be returned to a non-CD query.  If the cached
> data has the CD bit set it may be returned to a CD bit set query, if
> a SERVFAIL is cached it may be returned to a non-CD query, and if
> the cached data has the CD bit set, and there is a covering TA it
> may be locally validated and returned.  Otherwise this should be
> treated as a cache miss and the query repeated upstream."
 
As a bit of wordsmithing, may I suggest

   Data in cache with CD=1 but that has not been locally validated
   MUST NOT be returned to a query with CD=0.  [Note: it says that
   above too, I think.]  Cached data with CD=1 MAY be returned to a
   query with CD=1.  Cached Server Failure errors MAY be returned to
   queries where CD=0; alternatively, if the data is locally
   validatable (using a local covering trust anchor), it may also be
   validated and returned.  

I found the text you proposed hard to understand, but I think I got
its sense.  Is that right?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jun 2010 16:33:19 -0400

At 05:22 PM 6/7/2010, Andrew Sullivan wrote:
>opinion.  

There have been ample counter arguments.  But the counter arguments have not been persuasive.  They mostly just boil down to "I think I might possibly get better protection if I don't set the bit" - but have failed to explain how -absent specific configuration of the resolver to know - they would know such higher resolver could do a better job of validating.

BTW, I assume since you're citing your opinion, you're currently not wearing your chairmans hat?

>The text already suggests that for most cases, it's better

My complaint from the start with this text is that "may wish to set" is not standards language.  Each implementer will read this text differently.    And frankly, this text could be read as "a validator can randomly set the CD bit on all upstream queries"

Pick a default.  Make that "MUST" or "unless otherwise configured MUST".  Make the other option "SHOULD IMPLEMENT an option to [do the opposite]"

So either :

For efficiency, a validator, unless otherwise configured MUST set the CD bit on all upstream queries when it has a trust anchor at or above the QNAME (and thus can reasonably expect to be able to validate the response).  A validator SHOULD have an option to clear the CD bit such queries, either as a global matter (CD bit is cleared on all queries) or for specific groups of QNAMES covered by specific trust anchors.

or 

To allow for the possibility of validation at an upstream resolver, a validator, unless otherwise configured, MUST clear the CD bit on all upstream queries for which the downstream query did not have the CD bit set.  For efficiency, a validator SHOULD have an option to set the CD bit on either all upstream queries or a specific group of QNAMEs (e.g. a subset of all trust anchors) when it has a trust anchor at or above the QNAME (and thus can reasonably expect to be able to validate the response).

If you have an argument why standards language is not appropriate here, I'd love to hear it.  At this point I think the second block of text above is the poorer choice,  but I can live with it as a default.  But let there be a default and a mechanism to switch.

>intermediate resolver shouldn't cache CD=0 data, but I presume not.

The argument is about whether or not you need to keep track of the validation/CD bit set status of cached data.  This basically says that if you're implementing a validating resolver, and you cache non-validated data (because the CD bit was set), you need to keep track of that status.  But it also says, its ok to *not* cache CD bit set data.  

There are a number of possible states for data in cache:

1) populated - manually installed and permanent
2) SERVFAIL - queried upstream but got a validation error
3) cached - queried upstream without a CD bit set (if DO is cleared, no ancillary data) - (what to call this? - it may have been validated upstream, but no way to tell.  Locally, there may or may not be a TA - so maybe some local validation so maybe two classes?)
4) cached but not validated - queried upstream with the CD bit set, have a local covering TA, validation deferred because the query had the CD bit set
5) cached and validated - 4, but local TA validation is done
6) cached as bad - 4 but local TA validation returns bogus
7) cached, not validated, unvalidatable - queried upstream with the CD bit set (because of the query), but does not have a local covering TA.

If you get a non-CD bit query, you can mostly answer from cache - but class 4 data will require being turned into class 5 or 6.  Class 7 will require a re-query.

If you get a CD bit query, you will need to query upstream for class 2, and may need to repeat the query for the ancillary RRSIG and DNSKEY data for other classes if not cached.

If you don't cache CD-bit set data, then everything in cache is "validated" and can be returned to a non-CD query.  Otherwise you need to keep track of the validation status and the CD bit status.

>    bit set.

I think not...  because the above can be read to say that its optional to return non-validated data if the CD bit is set and that particular item is non-optional.  It also doesn't cover the case where the resolver doesn't have a covering TA for the data.

>  In that case, the intermediate resolver MAY defer

See above.  QNAME + CD=1 is a different query than QNAME + CD=0.  If you decide you don't want to cache CD=1 responses, then you can throw away that result - but part of the reason for having an intermediate resolver is to cache data and reduce upward queries. 

Let's take a somewhat real example - IN-ADDR.ARPA a few days back.  Let's say lots of folk set up their stub resolvers to set the CD bit on all of the IN-ADDR.ARPA queries to get past the brokenness.  Not caching the CD=1 queries results means a sh*t load more inverse queries going all the way up the stack. I don't know what that load is.   I don't even know that this is a reasonable scenario, but I do know that I don't want to find out later on that we've built ourselves a system that has even more failure modes than current.  So that implies to me that the validating resolvers need to cache results from both types of queries separately (or at least logically separate).

>its sense.  Is that right?

Yup.. basically a translation of CD bit set to CD=1 etc...

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Jun 2010 17:09:04 -0400

On Tue, Jun 08, 2010 at 04:33:19PM -0400, Michael StJohns wrote:

> There have been ample counter arguments.  But the counter arguments
> have not been persuasive.  They mostly just boil down to "I think I
> might possibly get better protection if I don't set the bit" - but
> have failed to explain how -absent specific configuration of the
> resolver to know - they would know such higher resolver could do a
> better job of validating.

Well, maybe they're planning to do that specific configuration.  I
don't know, neither do you, and we have existing text that permits
such operation.  This is not supposed to be a revision of DNSSECbis,
but a clarification of it.

> wearing your chairmans hat?

On the contrary, I am acting as chair and ruling on what rough
consensus I think is possible.  We seem to have two sets of
strongly-held views here.  The documents we are trying to clarify
appear to allow either interpretation.  Your proposal is to close off
one interpretation; but I think that in the absence of strong
consensus (which we clearly do not have), it would be wrong to do so
in a document purporting to clarify something.  If this document does
not get immediate, "Yes, that's obviously what 403x meant" from
everyone, then it's not making a clarification.  Your proposed MUST
just doesn't meet that test.  Sorry.

> My complaint from the start with this text is that "may wish to set"
> is not standards language.  Each implementer will read this text
> differently.  And frankly, this text could be read as "a validator
> can randomly set the CD bit on all upstream queries"
 
I don't think that's allowed to begin with, and it sounds like an
enormous expansion of the scope of the problem here.  I'd like a
plausible reading of RFC 4035 §3.2.2 that says you can just do random
things with the CD bit.  The only problem, as I understood it, was the
interaction of all of this with a cache, and what to do in the case of
data in the cache that suggests issues.  That issue is stickier in the
presence of intermediate caches and different security awarenesses,
but it's not actually made any different. Remember, we're clarifying
the previous RFCs, not replacing them.  We don't actually need to
restate everything in them.

> The argument is about whether or not you need to keep track of the
> validation/CD bit set status of cached data.  This basically says
> that if you're implementing a validating resolver, and you cache
> non-validated data (because the CD bit was set), you need to keep
> track of that status.  But it also says, its ok to *not* cache CD
> bit set data.

Your proposed text does not say that.  SHOULD is not "well, this'd be
a good idea".  It means that you'd better have a pretty good reason
why not.  That was why I suggested some modifications.  Moreover, it
wasn't clear to me whether it was supposed to have implications for
caching data with CD=0.

> If you get a non-CD bit query, you can mostly answer from cache -
> but class 4 data will require being turned into class 5 or 6.  Class
> 7 will require a re-query.
> 

I think everyone is in agreement about that, and all we're trying to
do is come up with text that is easy to understand.  

> I think not...  because the above can be read to say that its optional to return non-validated data if the CD bit is set and that particular item is non-optional.  It also doesn't cover the case wh…

Hrm, you're right about the MAY.  But we can fix that.  

   When caching, a security-aware intermediate resolver MAY return
   data without validating it only if the original query had the CD
   bit set.  In that case, the intermediate resolver MAY defer
   validation of the data, but MUST mark the cached data as
   non-validated until local validation actually occurs.  It MUST NOT
   return the cached, unvalidated data to a query with CD=0.  As
   specfied in [RFC4035], Section 3.2.2, it SHOULD return the data, 
   regardless of any validation, to a query with CD=1.

That's a little awkward, but I still find it clearer than what you
proposed before.  The no-covering-TA is a red herring.  If the
intermediate resolver can't validate the data because it doesn't have
a covering TA, then it can't cache (that's entailed by the rule the
way it's written here).  If you really want, we could add another
sentence after CD=0 that says "That includes data unvalidated due to
want of a covering trust anchor."
 
> See above.  QNAME + CD=1 is a different query than QNAME + CD=0.  If
> you decide you don't want to cache CD=1 responses, then you can
> throw away that result - but part of the reason for having an
> intermediate resolver is to cache data and reduce upward queries.
> 

The "see above" there clarifies nothing, since you then note that you
_could_ just not cache the result.  I agree it'd be stupid, but we're
not the DNS intelligence police.  We're here to specify what is
required for interoperation, and telling people how they have to
implement is not our job.

I do not believe anyone disagrees with you that caches need to
differentiate between data that they got with CD=1 and data they got
with CD=0.  I think the text proposed above makes that point, but I'd
be delighted if someone came up with something clearer.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jun 2010 18:22:23 -0400

>but a clarification of it.

DNSSEC is silent both on the setting of the CD bit in the upstream in this case AND on how you determine how to set it.  The fact that someone picked one and ran with it doesn't mean that is what we should document.  I do agree though that we should probably not prohibit that model of operation.

>just doesn't meet that test.  Sorry.

 I really don't care about which MUST happens, I just insist that at least one of them does.  I've said this now in at least 3 messages - would you please move on? 

And with respect to "consensus"  exactly how many people do you believe have expressed an opinion on this in the last go around?  I'll give you a hint, not counting you and me and the document editor, it was less than 2. And the document editor was mostly trying to find "simple" text.   Plus one side comment about multiple key types that was a clarification rather than taking a side. 

>plausible reading of RFC 4035 Â§3.2.2 that says you can just do random
>things with the CD bit.  

*sigh* Its not the plausible reading of 4035, its the plausible reading of the -11 bis.   "For efficiency" and "may set"  does not define the conditions under which the bit is set, does not define the default behavior, does not define the configuration options for non-default behavior, etc etc etc.  So "random" as a possible behavior is not excluded by 4035 and not by the text in -11.

Let me ask you - specifically.    Given the text of -11, how - EXACTLY - would you  set the CD bit in the upstream given a covering TA?   Please be specific and describe how your approach is what is meant by the current text.

If you say "operators choice" then I say, "what are the knobs and what's the default?".  If you say "implementers choice" then I say "what must all implementers do and how do I as an operator recover from a bad implemetation choice?"  If you say "it depends" then I say "ok, so what you're saying is that from the view point of a querier the result from sending a non-CD bit query to a validating resolver implementing your 'it depends' or 'may set' is a random setting of the bit since the querier has no predictable way of determining how the bit is set"

Pick one well defined approach that a querier can depend upon - I really don't care which at this point in time.  Make it the common default behavior for all resolvers.  Provide a mechanism to opt out of either of them. We're done.

I asked you to explain why standards language wasn't appropriate... let me ask that again. I've given you two different blurbs that describe both my desired option and the "don't set the bit by default" option.  Both of these also provide the escape valves to do the other thing.  Pick one  of mine, or explain why the current text is better and really does say what you think it does in a consistently implementable way.

>The only problem, as I understood it, was the
>data in the cache that suggests issues. 

Nope.  Two different issues.  

> That issue is stickier in the

Actually, the previous RFCs pretty obviously didn't consider what would happen if there were multiple cache/validators between authoritative and querier.  It wasn't an issue in non-DNSSEC with multiple caches, but validating caches are not passive repositories of data.  

>wasn't clear to me whether it was supposed to have implications for

Actually it does.  It may not say it clearly enough, but that's what was meant. And if you read all three paragraphs of the text, it really does say that.

With respect to this - the normal rule is that if you cite one condition of data, you aren't actually saying anything about any other condition of data.  So if you need to clarify this doesn't apply to CD=0 data, feel free to add text.

>want of a covering trust anchor."

Still not correct.  

If you have CD=1 data without a covering TA, you want to cache it, but not return it to CD=0 queries (because there can be other CD=1 queries).  If you get a CD=0 query, you need to requery to allow any upstream validation to take place.  

If you have CD=0 data without a covering TA, you can return it to a CD=1 query.

If you have a CD=0 SERVFAIL cached, you need to requery.

My original text was:

> from an upstream (server side) query which had the CD bit set. 
[Implication is that you don't have to cache CD=1 data if you don't want to, but if you do you need to keep track]

> If

[This has language that says if you have a covering TA for the data, you can validate and return it]

And there was additional text that said:

>Security aware intermediate resolvers SHOULD cache SERVFAIL responses returned from an upstream query. They MUST cache the state of the CD bit in all upstream queries as well.  If a security aware intermediate resolvers receives a query for data which has a SERVFAIL cached, but with the CD bit set, the resolver MUST set the CD bit on the upstream query and cache BOTH the SERVFAIL and the returned data.  Data in cache with the CD bit set which has not been locally validated MUST NOT be returned to a non-CD query.   If the cached data has the CD bit set it may be returned to a CD query, and if a SERVFAIL is cached it may be returned to a non-CD query, otherwise this should be treated as a cache miss and the query repeated upstream."

With a note that I might have missed corner cases.  But this section goes with the other and hopefully makes clear which data and which setting of the CD bit.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 13:36:38 -0400

> Nope.  Two different issues.  

Ok, good, we have two issues, so I'm going to split continued
discussion.  See more follow-up in a minute.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 14:28:32 -0400

Dear colleagues,

On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote:

> Actually it does.  It may not say it clearly enough, but that's what
> was meant. And if you read all three paragraphs of the text, it
> really does say that.

So since we're in agreement that we need text here, and since at least
one person (me) doesn't understand your proposed text without
re-reading it four or five times, I think we need different text.
Let's try again.  I'm going to be verbose to start with, and then
maybe we can whittle down if we can all agree.

    A security-aware recursive name server might receive queries either
    with CD=1 or with CD=0.  In addition, it might have cached data that
    is the result of a query made with CD=1 or CD=0.

    A general rule is that each cache entry MUST include some
    indication of whether it came from a query performed with CD=1 or
    with CD=0, or else that all cache entries MUST be treated as
    though they were performed with CD=0.  This rule prevents data
    that does not validate, but that may be cached to respond to CD=1
    queries, from being returned in response to a query with CD=0.

    When returning data for a query with CD=1, a validating
    intermediate resolver MAY return data without validating.  It MUST
    NOT return data without validating to a query with CD=0.  This
    applies both to data that is available from cache, and to data
    that must first be fetched before returning it.

    A validating resolver MAY cache unvalidated data, and even data
    that cannot be validated due to lack of a covering trust anchor,
    in order to respond to queries with CD=1.  Such cached data MUST
    NOT be used to respond to queries with CD=0.  If the validating
    resolver subsequently validates that cached data, then it MAY use
    it to respond to queries with CD=0.

    If a validating resolver has a cached response of RCODE=2 (server
    failure), and then receives a query with CD=1 to its name server
    side, then it SHOULD [Note 1] perform the query again with CD=1
    from its resolver side.  The result of that query is returned to
    the query received on the name server side.  If the resolver is
    able to validate the answer, then it MAY replace the cached
    RCODE=2 response.  Otherwise, it MUST either leave the existing
    cached response alone, or cache both responses along with an
    indicator of the CD bit setting that engendered them.

* Note 1: 4035 section 3.2.2 uses SHOULD for responding with all the
data to CD=1, so I am pretty sure anything stronger than SHOULD would
be a protocol change.

I think that covers everything we have discussed on this topic.  I'm
not at all sure that this sets all the rules according to the way
people currently want them to be set, but at least it's broken into
one paragraph per case so that we can change specifically the text
there.  So have at it, please.  More participants would be good.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jun 2010 14:47:01 -0400

On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote:
> 
> DNSSEC is silent both on the setting of the CD bit in the upstream
> in this case AND on how you determine how to set it.  The fact that
> someone picked one and ran with it doesn't mean that is what we
> should document.  I do agree though that we should probably not
> prohibit that model of operation.

What case exactly are we talking about now?  I am confused (even more
than usual).  RFC 4035 Section 3.2.2 says this:

   The CD bit exists in order to allow a security-aware resolver to
   disable signature validation in a security-aware name server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit from a query
   to the corresponding response.

   The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest
   of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side.  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.

Is your complaint that a poor implementation could take the above to
mean that the resolver side of a recursive name server could set CD=0
even though it knows that the name server side got CD=1?  I thought
that was covered by the text in the draft, section 5.9, that says

   When processing a request with the CD bit set, a resolver SHOULD
   attempt to return all responsive data, even data that has failed
   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
   processing a request with the CD bit set to set the CD bit on its
   upstream queries.

Right?

If instead what you are trying to insist upon is some rule about what
an originating client has to/ough to do with the CD bit when it has a
TA covering a query (which seemed to be your focus in, e.g.,
http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01397.html),
I see very little support in the long history of this discussion for
that insistence.  I also don't see why the protocol needs to say
anything about this: it seems to me to be a purely local policy, and
one that could be sensitive to local conditions.  I've read,
repeatedly, your assertions that your view is the most reasonable, and
while I think it is an entirely reasonable thing to do, I do not
believe the protocol is designed to require this.  So on top of
everything else, it seems to me that what you are demanding is a
protocol change, and I don't think this document is the place to make
that change.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 09 Jun 2010 20:28:04 -0400

>    is the result of a query made with CD=1 or CD=0.

Yup.

>    intermediate resolver 

>MAY return data without validating. 

It MUST return the data regardless of validation state. If there is a local covering TA, the resolver MAY defer validation unless and until it receives a CD=0 query.

> It MUST
>    NOT return data without validating to a query with CD=0. 

It MUST NOT return data covered by a TA to a query with CD=0 unless it has been locally validated.  

> This

>    NOT be used to respond to queries with CD=0. 

No - if you don't have a covering TA, you have to pass it on. You have no way of validating it.  Or how would you decide whether or not to pass it on?

> If the validating

Yep, but covered in my restatement above

>    from its resolver side. 

Why SHOULD?  If I don't then I have to return the SERVFAIL to the querier which really seems wrong for a CD=1 query.  I believe this is MUST.  4035 was wrong.  4033 has the philosophy for the CD bit and 4035 is out of step with it.  the CD bit is the escape mechanism to bypass a resolver that may not actually know why you're asking the question.

> The result of that query is returned to

Yup.

>data to CD=1, so I am pretty sure anything stronger than SHOULD would

Nope, its a resolver behavior change - it doesn't change the meaning of the bits on the wire, just the processing rules.  And seriously, 4035 section 3.2.2 is pretty poorly written - it doesn't even say to set the CD bit in the upstream query.  It just says to pass the state of the CD bit to the resolver side....  

And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable.  

Does any validating resolver implementation use the SHOULD escape clause? E.g. doesn't pass on non-validated data to a CD=1 query?  If not, then changing this to a MUST has no affect on the Internet.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Jun 2010 11:27:40 +1000

DNSSEC works well in iterative resolvers because the resolver
	can ask the validator "is this answer good" and discard it
	if it isn't and move onto the next server / wait for the
	correct answer.

	DNSSEC works well in stub resolvers if the caching servers
	in use have the same trust anchors.  The caching servers
	reject the bad answers supposedly from the authoritative
	servers and the stub basically check that the answer was
	not tampered with between the cache and the stub.

	Trying it get disjoint sets of trust anchors to work in
	series requires a lot more state to be shipped back and
	forth between clients and servers to allow the upstream to
	know that the previous responses were bad and to try different
	sources.

	CD basically helps when the clocks are wrong or when you
	want to debug as it allows you to see what the validator
	is seeing.  It can't fix the disjoint sets of trust anchors
	problem.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Jun 2010 14:10:33 -0400

On Wed, Jun 09, 2010 at 08:28:04PM -0400, Michael StJohns wrote:
> It MUST return the data regardless of validation state. If there is
> a local covering TA, the resolver MAY defer validation unless and
> until it receives a CD=0 query.

The second sentence there just muddies things -- I think it belongs in a different
paragraph.  So up to here:

   When returning data for a query with CD=1, a validating
   intermediate resolver MAY return data without validating, and
   SHOULD, if possible, return the requested data on the name server
   side regardless of whether the data is cached or validated.

This text addresses your concern that the previous version could be
read as saying that the intermediate resolver may _not_ return the
data at all -- I find that reading a little strained, but I get it,
and you're right that we need to be very clear.  This says SHOULD
instead of MUST following 4035.  See more on this below.

> It MUST NOT return data covered by a TA to a query with CD=0 unless it has been locally validated.  

In this case, I think the MUST NOT, unless is really a SHOULD NOT.
Continuing from above, then:

    It SHOULD NOT return data without validating to a query with
    CD=0.  The exception is when the security aware recursive name
    server does not have a trust anchor that allows the validator to
    construct an authentication chain.  In that case, the recursive
    name server uses the unvalidated data to respond to every query,
    as though the name were unsigned, in keeping with [RFC 4035]
    section 5.1.  This applies both to data that is available from
    cache, and to data that must first be fetched before returning it.

    A validating resolver MAY cache unvalidated data in order to
    respond to queries with CD=1.  The validating resolver MUST NOT
    respond to queries with CD=0 using such cached data unless the
    data cannot be validated because of the lack of a covering trust
    anchor (see above).  If the validating resolver subesequently
    validates that cached data, it MAY use it to resond to queries
    with CD=0.

Ok?

> Why SHOULD?  If I don't then I have to return the SERVFAIL to the querier which really seems wrong for a CD=1 query.  I believe this is MUST.  4035 was wrong.  4033 has the philosophy for the CD bi…

The reason for the SHOULD is because that's what 4035 says, and 4035
defines the protocol.  Changing this is just a modification to the
protocol, even if you want to call that instead a "resolver behaviour
change".  We have no basis at all to decide that 4033 is more
authoritative than 4035 on this: they're both products of the same
group, at the same time, working on the same problem, so one can just
as easily say that 4033 is wrong and 4035 is right.

Speaking personally, I wish it said MUST, but it doesn't.

Speaking with my chair hat on, I would be entirely happy, however, if
a large number of people now came out of the woodwork to say, "It
should be MUST."  Then we can make that update.  But until we hear
that, I have to say that there is not consensus to make this protocol
change, so we cannot.

> And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable.  

I put the same "if possible" as was in 4035 in the text above.  Ok?
 
> Does any validating resolver implementation use the SHOULD escape clause? E.g. doesn't pass on non-validated data to a CD=1 query?  If not, then changing this to a MUST has no affect on the Interne…

I invite you to go out and test this.  I don't know, and I don't know
who would, since I don't know that we have an enumeration of all the
validating resolver implementations in the universe.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 11 Jun 2010 15:56:18 -0400

>   queries, from being returned in response to a query with CD=0.

I think you're saying here is that you can either cache things with an indication, or refuse to cache things that were created as the result of a CD=1 query?   I think this still is missing the point.  

For a CD=0 query, If you have data with CD=1 in cache, you can either locally validate it (if you have a covering TA for all of the data), or you need to repeat the query with CD=0.  You can't treat CD=1 data as CD=0 data unless you can locally validate it.

>instead of MUST following 4035.  See more on this below.

And this still doesn't get to the point of what the CD bit is there for.

"When returning data for a query with CD=1, a validating intermediate resolver with cached data for the QNAME SHOULD return that data regardless of local validation status. Otherwise if it has no cached data or has only a SERVFAIL cached for the QNAME, it MUST repeat the query upstream with CD=1 and MUST return the result of that query to the querier."  

The SHOULDs and MUSTs are consistent with the fix to the CD=1 for CD=1 queries in -11bis as well as normal behavior of an intermediate resolver (must return result of query).

>    cache, and to data that must first be fetched before returning it.

OK - then what's the point of the local trust anchor?  This seems to be arguing both sides of the problem.  If you have a validating resolver in validating mode (e.g. not just logging how it might validate), then isn't the point that the resolver MUST validate the data covered by a TA and MUST NOT return unvalidated data?

I actually believe it should be possible for a validating resolver to go into log-only mode, but that's not what the SHOULD seems to mean here.  If we mean that, then we need to expand the text a lot more.  If we don't mean that, then what does SHOULD mean here?    If you mean that you should do (or should be able to do) local validation, but return unvalidated data - I say "HUH?"

>    validates that cached data, it MAY use it to resond to queries

No - because I think it disagrees with your previous paragraph.  I think this is getting worse not better.  This again confuses unvalidated (has a TA, but not locally validated) with unvaldatable (no local TA).

"A validating resolver MAY cache data regardless of its validation status.  If cached data is covered by a TA (and therefore be locally validated), the validating resolver MUST validate such data prior to using it to respond to queries with CD=0.  Cached data not covered by a  local TA may obviously be used to respond to any query without local validation. 

>I put the same "if possible" as was in 4035 in the text above.  Ok?

Nope... define "possible".  Its a subjective weasel word.  Who decides what's possible?  What are the criteria?  Pick something measurable such as "If in cache" "if received from the upstream server", etc.  In any event, see my restatement to your text including "possible" - it has more objective definitions.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 11 Jun 2010 16:18:58 -0400

On Fri, Jun 11, 2010 at 03:56:18PM -0400, Michael StJohns wrote:
> 
> I think you're saying here is that you can either cache things with
> an indication, or refuse to cache things that were created as the
> result of a CD=1 query?  I think this still is missing the point.

I was just trying to write an introductory general-principle
sentence.  I'm willing to drop it.

> For a CD=0 query, If you have data with CD=1 in cache, you can either locally validate it (if you have a covering TA for all of the data), or you need to repeat the query with CD=0.  You can't trea…

Hrm, this makes me think that we need two different paths in the text,
one for CD=1 and one for CD=0. I don't have time to try again from
scratch right now, but that might be clearer than what we've been doing.

> OK - then what's the point of the local trust anchor?  This seems to
> be arguing both sides of the problem.  If you have a validating
> resolver in validating mode (e.g. not just logging how it might
> validate), then isn't the point that the resolver MUST validate the
> data covered by a TA and MUST NOT return unvalidated data?

No, because that's not what 4035 says.  It says SHOULD NOT.  

> No - because I think it disagrees with your previous paragraph.  I think this is getting worse not better.  This again confuses unvalidated (has a TA, but not locally validated) with unvaldatable (…

It wasn't confused in my mind, but if it's not clear to you then we
still have a problem.  As I suggested above, I'll try to come up with
completely new text treating CD=1 and CD=0 separately.

I will note that your choppy way of suggesting text isn't helping me
-- I almost never understand what it is you're trying to say.  That's
undoubtedly my failing, but given that we clearly aren't getting very
far with this and I'm actually trying to understand, I take that to be
_prima facie_ evidence that the text you're supplying isn't clearing
things up.  If others want to chime in that this is all crystal clear
to them, I'm willing to defer.

> Nope... define "possible".  Its a subjective weasel word.  Who decides what's possible?  What are the criteria?  Pick something measurable such as "If in cache" "if received from the upstream serve…

4035 says "SHOULD if possible".  I don't know what that meant.
Perhaps those who were involved in its writing can elucidate.  I am
loathe to change this text without pretty strong agreement on what it
means, even if I wish it were different.

And I don't know which restatement you're talking about.  If you could
post a single, unbroken candidate text and say exactly where in the
draft you would like it and what you'd like to replace, I might have a
better grasp of your point.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 11 Jun 2010 20:03:01 -0400

From 5/14: 

>if query CD bit is set  
>if response is cached  
>if SERVFAIL is cached  
>Set CD bit upstream and query 
>Else  
>Return cached 
>else // response not cached  
>Set CD bit upstream and query 
>else // query CD bit clear  
>if response is cached  
>if cached response had CD bit set  
>if resolver has covering trust anchor  
>run validation against cached and return 
>else // resolver can't validate locally and data wasn't validated upstream  
>clear CD bit and query 
>else // prev data was validated upstream if at all  
>return cached data 
>else // response not cached  
>if resolver has covering trust anchor  
>set CD bit and query then validate locally 
>else  
>clear CD bit query and return