Re: Q-6: May security-aware resolvers cache "Bad" data?

[Paul Vixie <paul@vix.com>]

> Pro removal: the crypto equivalent of neg caching is possible.
> OTOH:        an attack of sending bad SIG's can "starve" a cache
> Pro removal: local policy can be to return data only if the cd bit is set
>               (i.e., saves cache from requerying itself on repeated queries)
> OTOH:        not caching it makes the requester try to get it from source
>               (i.e., will return it anyway on +cd, but won't remember)

negative caching functions as a "hold-down", which on the one hand helps
with authority-server and network load as well as average completion time
for queries which will fail due to broken validation chains, but on the
other hand means that a broken chain that is repaired will not be visible
during the negative caching window.

for name nonexistence we tolerate the hold-down because the chance that a
name doesn't exist due to an error is thought to be low compared to the
chance that it really doesn't exist.

for validation failure i think we can make the same assumption.  broken
validation chains are errors, not omissions, and if the minimum retry
interval before trying to validate it again is, say, five minutes, then
it's more likely to help than hurt the zone owner.

but as sam says:

> Maybe it should be left to the implementation.

an implementation who didn't want to do negative caching should not be
considered incorrect by the specification.  so, the language could be
softened from "must not cache" to "may cache, with a negative TTL of up
to the zone minimum ttl, if the SOA was gathered securely, or five
minutes, whichever is shorter."

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