> From: Stephane Bortzmeyer <[email protected]> > > While rate limiting by client IP address stops > > a reflection attack, it also turns off almost all DNS service to the > > client from the server. > > No one in his right mind limits simply by the client's IP > address. People typically also use the type of the request (today, > typically ANY). See my mini-HOWTO for Linux Netfilter in this thread.
That tactic makes limited sense if you assume that the bad guys are too stupid to see that they can bypass ANY filters with almost as much amplification with other query types such as A. `dig +dnssec www.nic.fr @ns1.nic.fr` offers amplification of more than 25X. +++++ ] but my point is that it works *today*, with *actual* attacks. So, it ] definitely helps but keep your eyes open, have alternative solutions ] in place and do not put all your eggs in one basket Yes, automated response rate limiting (RRL) is too small a basket to hold all of anyone's eggs. However, a static ANY filter amounts to trying to keep all of your eggs in a handkerchief. Manually maintained iptable rules are akin to hiring jugglers keep all of your eggs in the air. > (nobody asks "ANY > isc.org" in the real world, except the attackers). The common claim that no one uses ANY is so overstated that it is false. I use ANY to diagnose real problems in the real Internet. > I appreciate the BIND RRL patch and it is obvious to me that we must > continue the research in dDoS mitigation, but let's not drop the > mitigations techniques that work *today*. (The attackers are not > superhuman, they use imperfect techniques.) That's quite true, but advocating defenses such as static ANY filters or manually installed iptable rules is like avocating homeopathy in the fight against malaria. The suggested iptable tactic would be better if the phython program somehow automatically installed iptable rules. However, that might be too effective. > In actual deployments, some people may be unwilling or unauthorized > (corporate policy) to install "unofficial" patches on a production > server. That's why we should not reject blindly the OS-level rate > limiters (see my mini-HOWTO in this thread). A third party's iptable rules (not to mention a third party's program that generates the iptable rules) should get as much scrutiny as unofficial patches for BIND or NSD. Neither iptables hacks, a third party's phython program to generate iptables rules, nor DNS server patches (even if official) should be used lightly. The BIND patch includes a standard test suite in bin/tests/system/rrl Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
