Subject: Question about Section 4 of protocol-03

From: David Blacka <[email-masked]>
Date: Mon, 3 Nov 2003 15:06:16 -0500

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.  I seems 
to me that this is a radical departure from how most DNS software 
currently caches data (although I could be wrong).

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?

For instance, lets say a security-aware resolver gets the following 
response:

  HEADER: QR AA  RCODE=3
  QUESTION:
     www.example.net IN A
   ANSWER
   AUTHORITY
     example.net IN SOA ...
     example.net IN RRSIG SOA ...
     web.example.net IN NSEC example.net A NSEC RRSIG
     web.example.net IN RRSIG NSEC ...
   ADDITIONAL

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?

-- 
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: Paul Vixie <[email-masked]>
Date: Mon, 03 Nov 2003 20:34:20 +0000

> currently caches data (although I could be wrong).

i do not think that you're wrong about this.

> advice above, the resolver would have to re-query.

in this case your example is suboptimal since SOAs are never supposed to
be cached even in the pre-dnssec protocol.  however, your question is valid
if there were other authority data such as an NS RRset.  requery should not
be necessary in the non-SOA case.

> And would there by any harm in returning the results to "web.example.net IN 

not in my opinion.

---

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:
> 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.

> even returning cached NSEC records when directly queried for them?
...
> And would there by any harm in returning the results to "web.example.net IN 

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.

---

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).

---

From: [email-masked]
Date: Tue, 04 Nov 2003 11:58:33 +1100

>    RRs from one negative response to synthesize a response for a

	This precludes caching NXDOMAIN independent of query type
	which is in direct opposition to RFC 2308.

	We synthesis NXDOMAIN responses all the time in the non-
	DNSSEC world.  The only time this is a problem is when you
	have broken authoritative servers.

	I really have no problem with caches using the NSEC bitmask
	(or whatever replaces it) to generate NODATA responses to
	different query types.  If you have a NODATA response
	for example.net/IN/A and the bitmask says that AAAA doesn't
	exist you have all the information required to return
	a NODATA response to example.net/IN/AAAA.

	The only difference in the two responses above is in the
	QTYPE of the question.

	Again the only time this would be a problem is when you
	have broken authoritative servers.  You can't do this
	synthesis in the non-DNSSEC world but it make perfect
	sense to do it in the DNSSEC world.

	Failure to allow resolvers to synthesis NODATA responses
	will increase network traffic and cache memory footprints
	for absolutely no benefits.

	What is hard to do correctly is to synthesis NXDOMAIN
	responses to different QNAMES.

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Nov 2003 17:23:56 +0700

Date:        Mon, 03 Nov 2003 20:34:20 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

Off topic, but ...

  | in this case your example is suboptimal since SOAs are never supposed to
  | be cached even in the pre-dnssec protocol.

Where does that theory originate?

1034 actually says (page 27, sect 4.3.4) ...

	SOA RRs may be cached due to direct SOA queries

(the section is about other issues, but the direct words that say they
may be cached, in a context meaning that one must be aware of that, is
still pretty compelling evidence against your theory).

The closest I can come to a suggestion in line with your remark is in
3.1.1. of 1035 (page 11)...

		For example, SOA records are always distributed
                with a zero TTL to prohibit caching.

(which is part of the definition of the TTL field in RRs).   That, by
itself, doesn't say that SOAs cannot be cached, at most it suggests that
servers should send a 0 TTL to prevent caching - but it doesn't say whether
that is because of anything that the DNS demands, of whether it is just
what a server may want to achieve.   It isn't even clear here whether this
is something that was thought likely to be true of SOAs in general, or
whether this is just an example of what someone might want to do.

It is clear however, that in practice neither 0 TTL for SOA, nor don't
cache SOA are widely seen behaviours, eg:

; <<>> DiG 9.2.0rc10 <<>> @ns1.gnac.com. vix.com. soa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9646
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;vix.com.                       IN      SOA

;; ANSWER SECTION:
vix.com.                3600    IN      SOA     ns.lh.vix.com. hostmaster.vix.com. 2003101800 3600 1800 604800 3600

Note the TTL - not 0 on that SOA response.

What's more, from a different system (and not asking one of t he auth
servers directly, but just he local back end ...)

; <<>> DiG 8.3 <<>> vix.com. soa 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5
;; QUERY SECTION:
;;      vix.com, type = SOA, class = IN

;; ANSWER SECTION:
vix.com.                54m2s IN SOA    ns.lh.vix.com. hostmaster.vix.com. (
                                        2003101800      ; serial
                                        1H              ; refresh
                                        30M             ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

The answer does not have AA (came from a cache) and the TTL has been
decremented a bit from the 3600 secs (hour) that the auth servers
give out...   Neither the net nor the DNS seems to suffer from this,
so I can't think of any reason to attempt to retroactively create
a rule like the one you suggested exists.

kre

ps: and see sect 7.2 of 2181.