Please see the BIND9 Response Rate Limiting (RRL) page.
all-per-second parameter are always
dropped.
The slip value has no effect on them.
After one of the patches has been installed, `named -v` and `dig +short chaos version.bind txt` display the version string corresponding to a file name listed below.
These patches improve response policy rpz-nsip and rpz-nsdame performance. A new parameter min-ns-dots specifies the minimum number of dots in NS records which will receive NSIP and NSDNAME rpz checks.
For example, www.domain.com has one IP address and three DNS servers, ns1.domain.com, ns2.domain.com, and ns3.domain.com. There are a total of 3 IP records for those {ns1,ns2,ns3}.domain.com. There are 13 NS records for com, the next domain in the authority chain. There are 15 IP address for those those 13 gTLD NS records.
When BIND is built with the --enable-rpz-nsip or --enable-rpz-nsdname options on the "configure" command line, and when configured response-policy{} zones include rpz-nsip and rpz-ip records, the three NS domain names, {ns1,ns2,ns3}.domain, and their three IP address must looked up in the policy zones after www.domain.com and its IP address. With min-ns-dots set to its default of 1 in this new version, the rpz checks stop after checking those 7 names and addresses.
In the previous version or in this version with min-ns-dots set to 0, the 13 names and 15 address for the gTLD servers must also be checked. Those additional 28 checks cost significant resources, but are rarely desired or useful.
Rewritten responses are counted in the global and per-zone RPZRewrites statistics
There is changed text for the RPZ section of the BIND Administrators Reference Manual (ARM) describing the syntax of the new min-ns-dots parameter.
These patches include the rate limit patches listed below.
Please report RPZ problems to Paul Vixie, Vernon Schyrver, or the dnsrpz-interest mailing list.
These patches contain large internal changes in addition to the new min-ns-dot parameter and RPZRewrites statistics described above. The current versions of these patches fix bugs related to rndc reload in previous versions.
When two or more policy zones are configured, a database summarizing all configured policy zones is consulted to determine which if any policy zone has a policy triggered by a name or address. The result is a significant speed improvement on systems using several policy zones.
Because the changes in these patches are substantial, there is more danger that they contain bugs. There can be no promise about when features of either of these RPZ patches will appear in official BIND9 releases. A guess is that the single zone speed improvements might be officially released before the larger multiple zone changes. We are releasing these patches to collect bug reports.
The same changed text for the RPZ section of the BIND Administrators Reference Manual (ARM) applies to these patches.
These patches include the rate limit patches listed below.
Please report RPZ problems to Paul Vixie, Vernon Schyrver, or the dnsrpz-interest mailing list.
The patches above contain the January 8, 2013 version of the BIND9 Response Rate Limiting (RRL) code. They correct an error in the previous version of the BIND9 RRL patch reported by Irwin Tillman. They also include the single zone or the multiple zone RPZ change described above.
There is text for the BIND Administrators Reference Manual (ARM) describing the response-policy statement.
Please report RRL problems to Paul Vixie, Vernon Schyrver, or the ratelimits mailing list.
Each of these patches is half of the corresponding recommended Single Zone Response Policy Zone Speed Improvement patch above. The combined RPZ speed improvement and RRL patches are recommended, because these separate patches conflict with the separate RRL patches. DO NOT attempt to install one of these patches before or after one of the separate RPZ speed improvement patches unless you are prepared to merge their conflicting changes.
Each of these patches is half of the corresponding recommended Multiple Zone Response Policy Zone Speed Improvement patch above. The combined RPZ speed improvement and RRL patches are recommended, because these patches separate conflict with the separate RRL patches. DO NOT attempt to install one of these patches before or after one of the separate RPZ speed improvement patches unless you are prepared to merge their conflicting changes.
Each of these patches is half of a corresponding recommended Single Zone Response Policy Zone Speed Improvement or Multiple Zone Response Policy Zone Speed Improvement patch. The combined RPZ speed improvement and RRL patches are recommended, because these separate patches conflict with the separate RPZ patches. DO NOT attempt to install one of these patches before or after one of the separate RPZ speed improvement patches unless you are prepared to merge their conflicting changes.
