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 [email protected]
fax: +49-89-35655025 [email protected]
pgpcGZMNMkqqr.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
