[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q-6: May security-aware resolvers cache "Bad" data?
On Fri, 28 Feb 2003, Rob Austein wrote:
> Q: Is a security-aware resolver allowed to cache RRsets for which one
> or more SIG RRs exist but none of them validate?
>
> Discussion:
>
> Excerpt from RFC 2535, section 6:
>
> Data stored at a security aware server needs to be internally
> categorized as Authenticated, Pending, or Insecure. There is also a
> fourth transient state of Bad which indicates that all SIG checks
> have explicitly failed on the data. Such Bad data is not retained at
> a security aware server.
>
> This appears to rule out any form of caching for RRsets with
> signatures which do not validate, including any form of negative
> caching. Given the demonstrated need for negative response caching in
> insecure DNS, this prohibition seems ill-advised.
I'm not sure where negative caching fits into this. The RRsets returned
as part of a valid negative response should all be verified; there's
nothing in the negative reponse which would be classified as anything
other than Authenticated.
> Please also note that this appears to be dictating implementation
> details than just describing externally visible behavior, and that the
> RFC 2535 rule may require a security-aware recursive name server to
> leave itself open to denial of CPU-time attacks by requiring the
> server to repeat the same signature checks over and over again.
>
> Should we remove this prohibition?
As the prohibition is dictating implementation details, it probably should
be removed. It's reasonable to suggest this behavior, but the only thing
that should be enforced is that clients don't see bad data (clients should
possibly get bad data if they issue a query with CD, but I don't care too
much either way).
Brian
--
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/>