Subject: protocol-06 section 4.5

From: David Blacka <[email-masked]>
Date: Tue, 1 Jun 2004 10:37:59 -0400

I (still) have a problem with section 4.5 of
draft-ietf-dnsext-dnssec-protocol-06.

Here is the text of that section:

   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named
   RRset and any associated DNSSEC RRs.  The resolver SHOULD discard
   the entire atomic entry when any of the RRs contained in it expire.
   In most cases the appropriate cache index for the atomic entry will
   be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the
   response form described in Section 3.1.3.2 the appropriate cache
   index will be the double <QNAME,QCLASS>.

My first issue of this is that there is no "WHY" expressed here.
Given that this is a SHOULD, how is an implementer to know whether or
not to follow this method?

Second, this is essentially *implementation* advice, not a protocol
advisement.  Further, it is advising a caching strategy that, AFAIK,
the DNS community doesn't have much experience with.  Of course, I
personally have a hard time seeing how this method would cause
problems (other than lack of efficiency), but without experience, it
is hard to say.

Third, this section, since it says what resolvers SHOULD do, rather
than what they MUST NOT do, it stifles resolver innovation.

Fourth, it looks like a significantly less efficient caching strategy.
Here are some scenarios where a RRset level cache would be able to
respond out of cache, but a resolver using this strategy wouldn't:

When a subsequent query is for something returned in the authority
section of a previous response, like:

Q1: www.example.com IN A
R1: ANS: www.example.com IN A 1.2.3.4
    AUTH example.com NS ns1.example.com
         example.com NS ns.example.net
    ADD: ns1.example.com IN A 1.2.3.5

Q2: example.com IN NS

Q1: does-not-exist.example.com IN A
R1: AUTH: example.com. SOA ....

Q2: example.com IN SOA

And perhaps more damaging, when a query for an internally followed
CNAME is followed by a query for what the CNAME resolved to:

Q1: cname.example.com IN A
R1: ANS: cname.example.com IN CNAME www.example.com
         www.example.com IN A 1.2.3.4.
    AUTH: example.com NS ...
    etc.

Q2: www.example.com. IN A

There are probably more examples where this proposed caching strategy
results in a cache miss, where a per RRset cache would result in a
cache hit.

Am I the only one who cares about this?  Are resolver authors just
going to ignore this section?  Does BIND 9.3.x follow this section (I
don't think so, but I could be wrong)?

I would have written new language for this section myself if I
understood what problem it was trying to solve.  I've looked through
namedroppers archives and failed to find the genesis of this language
(I'm not saying it is definitely not there, but I couldn't find it).

If we, as a WG, can figure out what the problem is, we can write a
section that talks about what resolvers MUST NOT do.  If we cannot, we
should just drop the whole section.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

--
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: "Scott Rose" <[email-masked]>
Date: Tue, 1 Jun 2004 13:42:08 -0400

If memory serves me right...

The concern was having over-eager caching servers generate new responses
from stored NSEC RRs.  In some cases, the queried name, type may have been
updated, and the NSEC no longer valid.  For example:

query for b.foo.com  get:
a.foo.com NSEC c.foo.com CNAME

then someone queries for <a.foo.com  IN  A> and gets back the same cached
NSEC RR (that shows a.foo.com doesn't have an A RR associated with it).  In
this case it is correct, but in some cases, the NSEC RR for a.foo.com may be
out of date.  Caching servers also now know a wildcard RR when they see it,
so they may also be tempted to generate positive wildcard responses from
cached RRs.

It might be able to be re-written as:

"caching security aware name serves MUST NOT use cached NSEC RRs to generate
negative responses for queries unless those queries matched previous
queries.  Also, caching server MUST NOT generate their own positive wildcard
matches using previously cached wildcard RRs.

That text might be more confusing though.  It would need to be made very
clear (more clear than above).

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
> Sent: Tuesday, June 01, 2004 10:38 AM
> To: [email-masked]
> Subject: protocol-06 section 4.5
>
>

---

From: David Blacka <[email-masked]>
Date: Tue, 1 Jun 2004 15:41:48 -0400

On Tuesday 01 June 2004 1:42 pm, Scott Rose wrote:
> this case it is correct, but in some cases, the NSEC RR for a.foo.com may
> be out of date.  Caching servers also now know a wildcard RR when they see
> it, so they may also be tempted to generate positive wildcard responses
> from cached RRs.

I have a hard time seeing what you are describing as a serious problem.  I'm 
not saying that I believe that there isn't a serious problem here, but that I 
don't think that we have described it yet.

Right now (ignoring caches doing wildcard synthesis for the moment), what 
you've described is a cache that is, essentially, doing preemptive negative 
caching.  Unless the NSEC record is actually lying to you, the only problem I 
see for this is that, after a zone change, downstream clients will not see 
the zone change (assuming an RRset was added, not removed) for the duration 
of the NSEC TTL.

> "caching security aware name serves MUST NOT use cached NSEC RRs to
> generate negative responses for queries unless those queries matched
> previous queries.  Also, caching server MUST NOT generate their own
> positive wildcard matches using previously cached wildcard RRs.
>

This is sort of language I would like to see for section 4.5.  However, I 
think we need to justify it.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research