Hi, On Fri, Jan 03, 2014 at 11:15:26AM +0200, Eugeniu Patrascu wrote: > Maybe I should try this again: what I said was that on the recursive > resolvers dedicated for your clients you can add an extra layer of > protection in terms of dropping fake responses targeted at those servers by > the means of a local firewall setup on each box, not on a gateway like box.
You don't add a layer of protection, you add another layer of vulnerability. > My reasoning is that the kernel would be better at dropping unwanted > packets faster than the userspace DNS daemon can discard them. And with > very small timers enabled this should be feasible. The kernel might be faster in dropping - but effectively what you do is double the workload on the system under *all* conditions (because now the kernel has to keep state *and* the DNS server has to keep state), and the DNS server is much bettter in understanding what it needs to keep track of than a generic firewall layer which really doesn't understand DNS (and in particular "after a single-packet response, the state can be discarded"). > What I'm arguing against is the idea of rate limiting a service just > because it might be attacked and have your customers play the lottery with > their queries and try again if their packets are lost due to rate limiting. If there is no attack, rate-limiting won't kick in. This wasn't about "rate-limit to 10pps" but to "less than 10Mbit/s" - which you just won't see under normal circumstances, if you exclude well-known local recursives plus well-known remote recursive from the rate-limiting. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpcGZMNMkqqr.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/