* Andrew Sullivan:

> What I haven't seen much of is discussion of protecting caches _as
> such_. That is, given that we are going to cache, are there
> techniques that solve the dangers of a cache other than just
> preventing the cache from ever having the wrong data in the first
> place?=20=20


Here's an idea to contain the damage of a bad record by reducing the
amplification effect (attack one cache, compromise the network view
for thousands of clients):

If information enters the cache for the first time, you only use it a
fixed number of times before fetching it again from the network (say
10). If the usage count is reached, you fetch the data from the
network (even if the TTL has not yet expired). If it is still the
same, you double the counter. If it is different, you fail back to
the initial value.

This will cause additional DNS traffic for those who publish unstable
data. It is also reasonable to disable it during the cache warm-up
phase, and to keep records past their TTL (to avoid the cold start;
this makes sense for DNSSEC as well, were you often can avoid
cryptographic operations if the freshly fetched RRSIG matches the
stored one).

--=20
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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