• Print
  • Share
  • Dark

DNSRPZ performance and scaleability when using multiple RPZ zones

  • Updated on 25 Sep 2018
  • 2 minutes to read
  • Contributors

BIND 9.10 can be configured to have response policies. That means that it can be configured to give responses that are different depending on the identity of the querying client and the nature of the query. To configure BIND response policy, you put the information into a zone file whose only purpose is conveying the policy information to BIND. A zone file containing response policy information is called a Response Policy Zone, or RPZ, and the mechanism in BIND that uses the information in those zones is called DNSRPZ. 

The RPZ mechanism has not changed in BIND 9.10. The documentation in Building DNS Firewalls with Response Policy Zones (RPZ) is still almost current. What has changed in BIND 9.10 is that it is now possible to use as many as 32 separate RPZ files in a single instance of BIND, and that BIND is not significantly slowed by such heavy use of RPZ. Each one of those 32 policy zone files can specify policy for as many different domains as necessary. The limit of 32 is on the number of independently-specified policy collections and not the number of zones for which they specify policy.

In earlier versions of BIND in which RPZ was implemented, having more than one RPZ zone file required BIND to perform a separate lookup in each policy zone to see if there was a match. In BIND 9.10, the policy information is stored in a radix tree, in which simultaneous lookups across all policy zones can be performed in sub-linear time that is approximately proportional to the logarithm of the number of policy statements in the largest collection (RPZ zone). 

The improved implementation of RPZ for BIND 9.10 was provided by Vernon Schryver and Paul Vixie. It is faster because it is O(log n) in the size of the policy and because it can look up several items of data in parallel. The new limit of 32 results from the use of a 32-bit bitfield to identify the policy zones that affect a query. Previous implementations of RPZ were O(n) rather than O(log n).

We said above that the existing documentation is "almost current." The reason it is not totally current is that DNSRPZ in BIND 9.10 additionally supports drop policies and triggers based on the query client's IP address. The new RPZ-CLIENT-IP trigger clause and its use with a DROP policy is documented in the BIND 9.10 ARM in section

Was this article helpful?