On 03/01/14 09:45, Gert Doering wrote:
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
Worth bearing in mind that on modern DNS servers, the kernel is already
keeping some limited state - the short-lived/random source-port UDP
sockets used for the outbound queries. (there's also ip reassembly of
large responses and TCP sockets. of course). I can't remember off the
top of my head of those sockets are connected or not, which will affect
whether a 5-tuple or 3-tuple match is done.
I tend to agree that, gut feeling alone, the idea of putting an iptables
conntrack in front of all that doesn't seem like it will improve things
significantly. And of course, for all your valid outbound queries, you
burn precious kernel RAM and lock contention on a conntrack table which
you then have to walk for every reply, valid or otherwise.
It would be interesting to see some real-world numbers on this, to see
if it is a win or not. As I say, my gut says no, but gut != proof ;o)
Partly related:
A little while ago, our authoritative (not recursive) DNS were under
heavy source-spoofed ANY reflection attack. We rapidly deployed RRL,
which mitigated the reflection, but we still saw significant CPU being
burned managing the RRL state.
We didn't have S/RTBH at the time, so I rolled a system to tail the logs
in user-space, and when an RRL host triggered more than certain
thresholds, poke the IP into an iptables "ipset" which was used to
statelessly drop all UDP queries from that IP for 45 seconds.
This greatly improved matters, and had little-to-no adverse effects in
terms of CPU/RAM on the box. It seems to me that any system which can
detect "bad" replies would be better thresholding them into short-lived
stateless blocks, rather than short-lived stateful.
_______________________________________________
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/
