[c-nsp] rate limit dns

[Phil Mayers]

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.