Hello,
Lutz Donnerhacke implemented DNS-Dampening.
http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening
The implementation is available as patch for BIND9 only.
He told me that there is an other method preferred by the nsd developer.
It's called "Response Rate Limiting".
May one describe the idea behind rate limiting and compare it with Lutz' solution?
Thanks.
He told me that there is an other method preferred by the nsd developer.
It's called "Response Rate Limiting".
I think you're probably looking for [1], which is (loosely) based on the
RRL patches for BIND9.
-JP
Hi Andreas, Jan-Piet,
He told me that there is an other method preferred by the nsd
developer. It's called "Response Rate Limiting".
For NSD we have an RRL implementation, which follows what Vixie and
Schryver have written.
The NSD implementation makes fixed size allocations, and processing
time is kept small without spikes, much as Lutz describes that he wants.
The NSD implementation drops half and responds with TC to the other
half. This helps stop false positives. The main design goal was to
avoid false positives as much as possible, whilst helping the victim
as we can.
The NSD implementation compares the source IP and queried name and
type of the query, to avoid false positives. Dampening does not seem
to take the query name and type of response into account, lumping it
together.
Dampening uses a point system, and new IP addresses get extra points.
In some ways, lumping queries together may be useful to block them, in
other ways, they lead to false positives. If lumping queries together
is useful, we could add this as an option for NSD, to deal with a
system with many, many zones which all are exploited, but today, it
does not seem to add value.
I think you're probably looking for [1], which is (loosely) based
on the RRL patches for BIND9.-JP
Yes that describes our system. The result is pretty much the same,
with BIND, NSD or Dampening, because you start removing the bandwidth
towards the target. The senders are spoofed and do not have an
indication that you do so, and continue the input stream.
Best regards,
Wouter