Subject: Re: section 3.2 of protocol draft

From: "Scott Rose" <[email-masked]>
Date: Mon, 8 Dec 2003 09:25:01 -0500

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

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

> 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?
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

> 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/>
>

--
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: 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: "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 ..."]
> 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?

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)