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

["Olaf M. Kolkman" <olaf@ripe.net>]

> 
> If that's what you mean, I'd suggest not using the term "negative 
> caching", which is well defined (the caching of a negative response,
> where negative means either the host or type doesn't exist).  I'd use a
> new term, like "failure caching".
> 
> While forbidding failure caching might be going a bit far, caching
> failures is really not a good idea.  It means that if a server receives
> a spoofed response, it will cache the data, and use the cached failure
> as an indication to not try again.  This leads to obvious DoS attacks. 
> Not caching failures has other problems (bandwidth amplification
> attacks), but the ability to spoof a server into caching failure is much
> worse.


Just one comment:

There are two reasons for failure: Crypto failure and Expiration. You
may want to treat them differently.

If you do failure caching (I am not quite convinced you want to) you
want to do that based on local policy and use TTLs that are
relatively short (order 10s of seconds).



--Olaf



--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi


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