I don't disagree that limiting responses is a smarter tact than limiting requests, with respect to making an informed decision prior to discarding traffic. Having zone and query-type plus response data to evaluate the client hash is more information than looking only at source and destination IP address, as may be implemented at a firewall or within the O/S. Some of these data elements could also be tracked by an application-aware firewall.
For authoritative DNS servers, there's an approach to rate-limiting per-client request-count-over-time (or response-count-over-time) above the current legitimate client volume and below infinite that is useful to reduce the volume of large amplification attacks. The specific value can be argued as site -specific, but odds are good there's a number that remains somewhat high which should prove "good enough" as a default for the much of the installed base. Allow administrators the freedom to set the limit to any value and/or disable the feature, but shipping the product with a "smart" default may be viewed as a pragmatic step forward in noise reduction. Continuing to deploy into the wild without any rate-limiting isn't the best approach long term. Administrators need to be armed with options to implement countermeasures. The more accurate the countermeasure, the better. -----Original Message----- From: Paul Vixie [mailto:[email protected]] Sent: Monday, December 17, 2012 3:17 PM To: Patrick, Robert (CONTR) Cc: [email protected] Subject: Re: [dns-operations] DNS ANY requests from Amazon? On 2012-12-17 7:57 PM, Patrick, Robert (CONTR) wrote: > ... > > Where some customers haven't implemented rate-limiting within BIND, > mitigation is available at the O/S and network layer. As an example, there > are connection limits that can be enforced with iptables on Linux. > Per-source-IP connection limits can also be restricted on Cisco ASA firewalls > (and likely other vendor products). such rate limits are too coarse-grained for dns authority service. if you limit your request flows rather than your response flows, then your only choice is: too low, where a legitimate client asking a legitimately diverse set of questions, does not get reliable service; or, too high, where an attacker can get enough of your bandwidth directed at a victim to be damaging. OS-level rate limiting also lacks the ability to insert TC=1 responses on a statistical basis, thus transforming rate limiting into transaction delay rather than transaction loss. to make this work without breaking things, the rate limiting logic has to be within the server itself, and it has to be applied to responses not requests. > There is a patch available for rate-limiting inside BIND. see http://www.redbarn.org/dns/ratelimits for background, including patches (which are not currently supported by ISC) and a technical note (which looks a bit like an RFC that some day i hope RRL will deserve.) paul _______________________________________________ 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
