Re: section 3.2 of protocol draft

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

----- Original Message ----- 
From: "Miek Gieben" <miekg@atoom.net>


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