Subject: section 3.2 of protocol draft

From: Miek Gieben <[email-masked]>
Date: Mon, 8 Dec 2003 14:10:59 +0100

Hello,

I'm rereading the protocol draft again, and I'm wondering about the following
paragraph.

In section 3.2: Recursive Name Servers
2nd paragraph:

   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.  A security-aware recursive name server MUST NOT use NSEC
   RRs from one negative response to synthesize a response for a
   different query.  A security-aware recursive name server MUST NOT use
   a previous wildcard expansion to generate a response to a different
   query.

I don't "get" the first sentence. does that really say: "don't use the cache"?
If i'm a cache and i've just validated a DNSKEY in response to another query,
I cannot use that validated DNSKEY?

Further more, if this question is answered negatively (A cache can still be used),
i'm wondering why is this put in a protocol draft? Isn't this bordering implementation
details?

grtz Miek

--
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: Mon, 8 Dec 2003 09:25:01 -0500

----- Original Message ----- 
From: "Miek Gieben" <[email-masked]>

> I cannot use that validated DNSKEY?
I think the spec will be changed after Q-21 was resolved.  See Olaf's
previous email (Nov 27) about the proposed change.

Not quite - at least that is not what it is supposed to say.  The spirit of
the "MUST NOT" is that a caching server shouldn't try to format a response
out of RRsets from previous responses that were for different <QNAME,
QCLASS, QTYPE> combos.  It could, however use the previously cached
"www.example.com  A" RRset to answer another query for "www.example.com  A".
It shouldn't try to generate any new wildcard expanded responses if it has
cached a wildcard RR from a previous query.  Mostly because there is a
danger it could form an incorrect answer, or that two name servers could
generate different answers based on the contents of their individual caches.

Actually, this is mostly academic now - Q21 of the DNSSECbis questions was
resolved to use "MAY re-use NSEC RRs to format respnoses".  So the specs no
longer forbids it.

Using cached DNSKEYs to verify RRSIGs were always allowed, of course.

> i'm wondering why is this put in a protocol draft? Isn't this bordering
implementation
I agree this is the grey area between protocol and implementation/operation.
But the restriction is on what liberty a cahce has in generating responses
to queries, so it falls more on protocol (sending responses) than operation.

Scott

---

From: Miek Gieben <[email-masked]>
Date: Mon, 8 Dec 2003 15:44:19 +0100

[On 08 Dec, @15:25, Scott wrote in "Re: section 3.2 of protocol dr ..."]
> previous email (Nov 27) about the proposed change.

I've read that, but that concerns NSEC records ie. negative caching.

> "www.example.com  A" RRset to answer another query for "www.example.com  A".

Ok, I understand that, but makes the text from 3.2 the following illegal:
(i'm not sure of the following 2 replies actually will go to the same
nameserver, but suppose they do)

got query for nlnetlabs.nl -> cached (and verified!) key for .NL (while
                              following the chain of trust)
query for DS of some (other!) nl zone -> reply with DS + SIG, plus add the verified 
                                         key of NL in packet (and also the sig).

The question: can a recursive server add that key?

> resolved to use "MAY re-use NSEC RRs to format respnoses".  So the specs no

OK, I see, but that is negative caching.

> Using cached DNSKEYs to verify RRSIGs were always allowed, of course.

Also true, but either I don't understand the exact meaning of 3.2 or you
haven't understood the meaning of my email message :) Maybe the example
above makes it clearer?

> to queries, so it falls more on protocol (sending responses) than operation.

ok, then I would like to see where this discussions leads, 'cause the text
wasn't entirely clear to me. Maybe something must be added,

grtz Miek

---

From: Jim Reid <[email-masked]>
Date: Mon, 08 Dec 2003 15:22:45 +0000

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:

    >>    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.  A security-aware
    >> recursive name server MUST NOT use NSEC RRs from one
    >> negative response to synthesize a response for a different
    >> query.  A security-aware recursive name server MUST NOT use
    >> a previous wildcard expansion to generate a response to a
    >> different query.

    Miek> I don't "get" the first sentence. does that really say:
    Miek> "don't use the cache"?  If i'm a cache and i've just
    Miek> validated a DNSKEY in response to another query, I cannot
    Miek> use that validated DNSKEY?

No, it doesn't say "don't use the cache". Well, not to this
mother-tongue English speaker anyway. It says "don't use cached data
to compose or fill out an answer to a query you've not resolved". I
think the intention here is to cover things like glue or partial
responses from an authoritative server. If the resolving server has
previously resolved and validated the glue or other stuff that might
be missing from the authoritative server's response, the resolving
server MUST NOT add these things to the reply it returns to its end
client. That's my interpretation of this bit of the draft.

Perhaps the language could be made less opaque?

    Miek> Further more, if this question is answered negatively (A
    Miek> cache can still be used), i'm wondering why is this put in a
    Miek> protocol draft? Isn't this bordering implementation details?

Some clarification is needed on when and how cached data can and
cannot be used. This is an implementation detail that will be critical
to how the protocol gets implemented. :-)

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 8 Dec 2003 12:47:17 -0500

That seems reasonable.  It might be a good idea to clarify that test
to take different cases into consideration.  There is little danger in
adding previously cached RR sets into the additional section of another
response - I haven't considered all the cases.  Or narrowing the
restrictions to what (from cache) can and cannot
be placed in the answer section of a response.

I believe it might be necessary to have stricter conditions on forming the
answer section of a response, but be more liberal about using cached RR sets
in the other sections.  Which I believe your example demonstrated.

Scott

---

From: Miek Gieben <[email-masked]>
Date: Mon, 8 Dec 2003 19:25:22 +0100

[On 08 Dec, @18:47, Scott wrote in "Re: section 3.2 of protocol dr ..."]
> adding previously cached RR sets into the additional section of another

why is this dangerous? Isn't this the reason we have dnssec? If it is validated
I can cache it, if I can cache it, I can use it? With DNS this could be
potentially dangerous, with DNSSEC I cannot see why (if you only use validated
reponses).

> in the other sections.  Which I believe your example demonstrated.

ok,

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Tue, 9 Dec 2003 10:40:12 +0100

[On 08 Dec, @16:22, Jim wrote in "Re: section 3.2 of protocol dr ..."]
> Perhaps the language could be made less opaque?

Maybe the following is clearer:

A security-aware recursive name server MUST NOT attempt to answer a query by
piecing together non validated, cached data (i.e. glue) it received in response
to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes.  A
security-aware recursive name server MUST NOT use NSEC RRs from one negative
response to synthesize a response for a different query.  A security-aware
recursive name server MUST NOT use a previous wildcard expansion to generate a
response to a different query.

grtz
      Miek
--
Serenity now!
-- Frank Costanza (Seinfeld)

---

From: Jim Reid <[email-masked]>
Date: Tue, 09 Dec 2003 12:23:35 +0000

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:

    Miek> A security-aware recursive name server MUST NOT attempt to
    Miek> answer a query by piecing together non validated, cached
    Miek> data (i.e. glue) it received in response to previous queries
    Miek> that requested different QNAMEs, QTYPEs, or QCLASSes. 

Yes, it is clearer IMO. But I think the security aware server should
do that for all cached data, not just non-validated data. Suppose the
resolver gets a signed answer that says the next name after a.foo is
z.foo. Is it right for the server to infer that no other names exist
between a.foo and z.foo for as long it it caches that answer? If it
then gets a lookup for b.foo, should it respond with the already
cached answer or should it resolve b.foo and return the answer to that
to the client? [Suppose the authoritative servers for foo add b.foo
while the resolving server is still caching that NXT record for a.foo
pointing at z.foo.] There are valid arguments that either of these
options is correct (or wrong). A statement of what's the correct
behaviour for this scenario would be preferable to leaving this
undefined and ambiguous.

How about the text below?

	A security-aware recursive name server MUST NOT synthesise or
	augment responses, for instance to populate the Additional
	Section, using cached data from earlier lookups. Cached data
	MUST NOT be used in a response unless it results from a
	response to an earlier query that exactly matches the QNAME, 
	QTYPE and QCLASS for the current query.

---

From: [email-masked]
Date: Wed, 10 Dec 2003 00:03:08 +1100

> response to a different query.

	Why are we arguing over what it currently says?  The current
	text is overly restrictive.  We should be trying to determine
	firstly what we are going recommend that every server SHOULD do.
	What they MAY do, what the SHOULD NOT and MUST NOT do.

	At a minimum negative answers against the same QNAME and QCLASS
	need to be allowed again "Name Error" to bring the draft into
	alignment with RFC 2308.  "Name Error" is independent of QTYPE.
	(SHOULD)

	Also at a minimum negative answers against the same QNAME and
	QCLASS need to be allowed against "NODATA".  This is a extention
	on RFC 2308.  The NSEC bitmap clearly allows a cache to determine
	which types do not exist when the query was made.  All of these
	would return the same authority section.
	(SHOULD)

	Both of these cases allow a internally consistant negative
	answer to be returned.

	NXDOMAIN requires the two proofs to be returned
	* QNAME does not exist
	* Wildcard does not exist
	
	NODATA require one or two proofs to be returned depending apon
	whether the answer is from a wildcard or not.
	non-wildcard:
	* QNAME exists but does not have type
	wildcard:
	* QNAME does not exist
	* wildcard exist but does not have type

	What get more interesting is should we allow a cache to to
	take the knowledge that a previous positive answer came
	from a wildcard and just query for the wildcard.  My feeling
	in this case is NO.  You still need to make a query to the
	server so we don't save anything there.  We would potentially
	save one proof (QNAME does not exist) in the answer, however
	you combining the two answers could give a internally
	inconsistant answer.
	(SHOULD NOT)

	Following a wildcard CNAME can also produce a internally
	inconsistant answer if the CNAME refers to the same zone.
	CNAME chains also have this problem if they go back to a
	previous zone.  I suspect that we just have to live with
	this one.

	Another case mention at MN is where the QNAME and QCLASS
	matches a existing NSEC and the type is not in the bitmap
	however the NSEC was not learnt via the NSEC ownername.
	e.g. as one of the proofs in a NXDOMAIN or QNAME does not
	exist for a wildcard.

	I think this case can also safely be returned.
	(MAY)

	Next comes names that are within a span of a NSEC record.
	Theoretically it is possible to constuct a response from 
	these provided you also have the answer to the corresponding
	wildcard (NXDOMAIN, NODATA and positive) answer.
	(SHOULD NOT, MUST NOT?)

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