Re: section 3.2 of protocol draft

[Miek Gieben <miekg@atoom.net>]

[On 08 Dec, @15:25, Scott wrote in "Re: section 3.2 of protocol dr ..."]
> > 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.

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

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

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?

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

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?

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

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

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