[nsd-users] concepts against amplification using dnssec

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas, Jan-Piet,

On 01/17/2013 01:21 PM, Jan-Piet Mens wrote:
>> 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
> 
> [1] http://www.nlnetlabs.nl/blog/2012/10/11/nsd-ratelimit/

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ9/Z8AAoJEJ9vHC1+BF+NSjwP/j50o/c85qgEqyKAHKIKWUet
4zcZ2HO4mbxrra1PdT7JvX9SPSiyZkmK9sjfGan+YcgcmDkT/m/aE3N9BsbDjqTN
qYVLFcI/wfRamEDjfK+xS06cU6kWfcvJElQCi+nsOTLbfoamOfCdGZWXZF1dfEGU
6kJDnS7PwuIwqih7o9OkbKmpwF2O2K9y0Ni2MZAv2oveoHNMiv3dZCLI1J5VTDd5
YrIet2ZPf4YzKhQg4PoRajcmUOVFU93n1rJucCRWzxJLBeSEhE6spw1eVOoAsPQW
e0NBVuViWBHpSy0o+49/ZRgE+mYQVMzOzgc/FJxInhw8H4J5RXcHm96Ryeutx3uv
hgp+aZshEkvBMKN10mESVf+op9ib1kjE+Pn7zDZ6RbCuqbl/sDKx5sTNwwEcwQwh
Wqtss2940cAIZSdW35hdBoW256vKkbOJjzFLLjTDDHiGaU5NXxZOpUqzcPPcQ7/d
IAesQ5d3O25QHrBZk09Ce8WANqg9RTyZUojb43MUyCWw6iKggf5J1uMkj8OxztLF
r23e7jHRRlXupwWpslKiw2m3i5i6pbu654kNwhge7kGTtB8MaSOFi2Efx6veHDh6
dwCVA17HIwhrjI3Ke6FSM6PdMKj3A/6GJeNYGpXHaF1wFk2wZzm+bgynKtebDll1
tPuT6wG+xgDucbPZotLi
=ma3S
-----END PGP SIGNATURE-----