> From: "Patrick, Robert (CONTR)" <[email protected]>
> 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. Yes, you could do response rate limiting (RRL) within an application aware firewall by have the firewall do almost of all of the work of your DNS server. For example, your RRL mechanism (whether in a firewall or DNS server) must count all NXDOMAIN responses to a given IP address as identical to avoid spewing GBytes/sec of big signed NXDOMAIN responses about distinct random, invalid domains. `dig +dnssec asdf1234asdf.com @a.gtld-servers.net` gives a 1K NXDOMAIN. Referrals have a similar issue. A firewall that is as DNS aware as that should not waste the computing it has done to know whether to discard the response it computed to count. If things are ok, it should go ahead and send the response. Never mind that consistency, maintenance, and other problems that always come with duplicating things, whether definitions of constants in code or the big chunks of code and data that are a modern DNS server. > ... > 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. The right RRL value depends on each server's popularity. It might be reasonable to ship DNS software with a default rate limit suitable for modest servers (e.g. 5 or fewer responses/second) and expect big server operators to make adjustments. > Continuing to deploy into the wild without any rate-limiting isn't > the best approach long term. Neither is tolerating unnecessary open recursive servers and ignoring BCP-38. 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
