Re: section 3.2 of protocol draft

["Scott Rose" <scottr@nist.gov>]

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

----- Original Message ----- 
From: "Miek Gieben" <miekg@atoom.net>
To: "namedroppers" <namedroppers@ops.ietf.org>
Sent: Monday, December 08, 2003 9:44 AM
Subject: Re: section 3.2 of protocol draft


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


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