Subject: Re: Question about Section 4 of protocol-03

From: Rob Austein <[email-masked]>
Date: Mon, 03 Nov 2003 16:15:26 -0500

At Mon, 3 Nov 2003 15:06:16 -0500, David Blacka wrote:
> 
> The third to last paragraph of section 4 in 
> draft-ietf-dnsext-dnssec-protocol-03 says:
> 
>    A security-aware resolver SHOULD cache each response as a single
>    atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
>    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.
> 
> I think I missed the conversation that ended up advocating this.

Q-13, which timed out due to (apparent) WG apathy on the subject.

This came out of advice we received from several workshops, as well as
some analysis that Roy and I did a while back (and discussed with the
WG in, um, Yokohama, maybe -- in any case, those present at that WG
meeting appeared to agree that this was the right approach to take).

The basic problem is that there are two DNSSEC RR types which are so
weird that it's almost better not to think of them as normal RRs at
all.  RRSIG is really more a property of an RRset than it is an RR in
its own right (see previous discussion about RRSIG not forming proper
RRsets).  NSEC RRs are even stranger, because they're assertions about
zone structure and what they mean is somewhat context-sensitive.

The choice of SHOULD was deliberate, and was intended to guide
implementors to the least complex approach.  YMMV.

> I seems to me that this is a radical departure from how most DNS
> software currently caches data (although I could be wrong).

You're right for most traditional resolver implementations (the ones I
know about, anyway), although I gather that this may be changing for
folks who implement DNSSEC, due to the complexity of keeping track of
NSEC and RRSIG RRs.

> I do understand that caches must not return NSEC records inappropriately 
> (and that is stated elsewhere in the document, somewhere in section 3), 
> but is there a problem with caching other signed RRsets separately?  Or 
> even returning cached NSEC records when directly queried for them?
...
> And then subsequently gets a query for "example.net IN SOA".  Following the 
> advice above, the resolver would have to re-query.
>
> And would there by any harm in returning the results to "web.example.net IN 
> NSEC" from the cache?

I agree that it would be harmless to let the resolver find such an
SOA, and that it probably would be harmless to return the result from
that NSEC query as well.  Not sure how useful the latter would be,
given the restrictions on synthesizing negative responses and so
forth, but that's a separate question and not the one you asked.

--
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: David Blacka <[email-masked]>
Date: Mon, 3 Nov 2003 18:34:42 -0500

> zone structure and what they mean is somewhat context-sensitive.

[ I forgot to note that this behavior is actually mandated by section 3.2: 
   A security-aware recursive name server MUST NOT attempt to answer a
   query by piecing together cached data it received in response to
   previous queries that requested different QNAMEs, QTYPEs, or
   QCLASSes.
]

I guess I'm arguing that this approach is too restrictive, as we can think 
of a few examples where "piecing together cached data" is perfectly OK.  
Of course, feel free to point out that I totally missed the point and am 
horribly wrong.

I think it might be better to explain what caches MUST NOT do with these 
records.  I am thinking, in particular they

  MUST NOT use NSEC records inappropriately (this is already done in 
Section 3.2, I believe), and
  MUST NOT expire RRSIG records independently of the RRset that it covers 
(or something to that effect, I imagine).

The repercussions of this is that a cache cannot (at least) synthesize 
negative responses.  Actually the other sentences in the indicated 
paragraph in section 3.2 have some weasel-room in them: 

   A security-aware recursive name server MUST NOT use NSEC
   RRs from one negative response to synthesize a response for a
   different query.

So...the cache can use NSECs that appear as part of referrals?

Or, alternatively, the rational for mandating this caching approach could 
be put into the document.

> implementors to the least complex approach.  YMMV.

Then I think that it should be labeled as such: a simple approach that 
meets the requirements.

As it stands, the reasons for implementing the cache this particular way 
are unclear, so an implementer would have a difficult time understanding 
when this SHOULD could be ignored (and indeed, the text from section 3.2 
argues that it essentially should be a MUST anyway).

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