@lbutlr <krem...@kreme.com> wrote: > > > rate-limit { responses-per-second 10; }; > > Does that apply to local queries as well (for example, a mail server may > easily make a whole lot of queries to 127.0.0.1, and rate limiting it > would at the very least affect logging and could delay mail if the MTA > cannot verify DNS.
I don't recommend using response rate limiting on recursive servers. The principle behind RRL is that auth servers are queried by resolvers with caches, and a correctly-functioning cache will not repeat the same query very frequently, so it is reasonable to apply a rate limit on the auth servers. Recursive servers, on the other hand, are often queried by stub resolvers without caches. The query rate is then entirely driven by the application workload, and you can't apply a rate limit on the recursive server without causing serious trouble for the application. It can be especially bad because traditional cacheless stub resolvers are not good at error recovery, and when RRL hits, their retry strategy is likely to increase the query rate observed by the server, making things worse. If you are running an oldskool multi-purpose server that is recursive for its own daemons but authoritative for others, then you can use the `rate-limit { exempt-clients }` option so that RRL doesn't apply to recursive clients. But I wouldn't recommend a setup like this. (My auth servers have their /etc/resolv.conf pointing at my recursive service.) > Do these setting also need to be applied to the secondary servers? The settings I described are for public authoritative servers, i.e ones that appear in NS records. These servers can be primary or secondary (but are usually secondary). Secondary servers don't necessarily appear in NS records, and if they don't they are less likely to be exposed to this kind of attack. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Southeast Iceland: Westerly or southwesterly, 3 to 5, becoming variable 3 or less later in north. Moderate. Showers. Good. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users