protocol-06 section 4.5

[David Blacka <davidb@verisignlabs.com>]

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    <davidb@verisignlabs.com> 
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>