Response Policy
Zones (RPZ)

Response Policy Zones can turn your DNS into an additional firewall layer for your network security.

Starting at $2k / year.

sales@cleanbrowsing.org

What is RPZ (Response Policy Zones)?

Response Policy Zones - aka RPZ, is security specification and protocol to enhance DNS resolvers with security inteligence about the domains it is handling. It was designed by Paul Vixie (author of Bind) to allow for custom filters and signatures that DNS operators can use to comply with policy and security requirements. They allow anyone running a DNS resolver to restrict access to content that is potentially malicious or unwanted.

RPZ also makes it easy for information sharing (via zone transfers), so companies can load an RPZ feed from other providers to improve their detection rates.

The use of RPZ can turn your DNS into a DNS firewall to prevent connections to malicious domains, spam and on some cases, even adult content. RPZ is supported by most DNS software, including the two most popular: Bind and PowerDNS.

RPZ actions are evaluated before the Resolver replies back to the client.

[client] ---> [DNS Resolver]  <---> [RPZ Policies]  <---> [DNS Cache | DNS Authoritative]
   ^               |                 (Drop request)
   |_______________|                 (return NXDOMAIN)
									 (change IP)

Most RPZ zones can contain thousands (if not millions) of domains and the RPZ implementation on both Bind and PowerDNS allows such big zones to be loaded without much performance penalties.

Who needs RPZ?

RPZ was designed for DNS operators running their own DNS software. If you are using an external resolver (like CleanBrowsing or OpenDNS), you need to rely on your 3rd party provider for the filtering. If you are just looking for a DNS resolver to filter malicious domains or adult content, you can leverage our own CleanBrowsing.

CleanBrowing RPZ FAQs
This section will answer some ofthe more common questions we get about our RPZ feed.

No. The CleanBrowsing feed is specific to malicious domains. This includes Phishing, Malware, Spam and other similar domains working to perform nefarious acts on the network.

Yes. We leverage third-party feeds and merge that with our own intelligence feed. We clean and aggregate the data according to the ebbs and flow of the threat landscape.

The feeds are updated every 3 hours.

The number fluctuates based on the market, but it ranges between 150 - 250k.

Don't find what you're looking for? Drop us a line...

We love working with individuals and organizations to better understand what they need, and how we can help.

Getting started with RPZ on Bind.

We are assuming you have your own resolver and Bind configured. The default configuration will be at /etc/bind/named.conf or /etc/named.conf on most Linux distributions, so that's where you need to make your changes.

The easiest way to get started is by building a simple policy rule to block access to 2 malicious domains (in our example: badsite1.com and *.badsite2.com). You start by adding a response-policy entry inside your bind options { } block and where you have your zones configured (generally at the bottom of the file) you add the zone for the malicious domains:

response-policy { zone "malicious-domains.rpz"; } break-dnssec yes qname-wait-recurse no max-policy-ttl 7200;
..
zone "malicious-domains.rpz"{
type master;
file "/etc/bind/malicious-domains.rpz";
};

With that set, you now need to create a file called malicious-domains.rpz with 2 entries to block badsite1.com and all subdomains under badsite2.com:

$TTL 2h ; default TTL
@SOA nons.blocked.com. noemail.blocked.com. 2018031404 12h 15m 3w 2h
@NS nons.blocked.com

badsite1.com CNAME .
badsite2.com CNAME .
*.badsite2.com CNAME .

Once you restart named, it will return a NXDOMAIN for badsite1 and badsite2.com. If you have a list of malicious domains, you can add them following the same format to expand your rules.

Note that you can do a lot more than just returning NXDOMAIN (not found). You can re-map the IP to somewhere else, drop the response, etc. To give another example, you can point badsite3.com to 1.2.3.4, with the following:

badsite3.com        A 1.2.3.4
*.badsite3.com      A 1.2.3.4

The Zytrax RPZ page has a lot more examples and ideas on what else you can do with RPZ

RPZ on Bind as a Slave

However, most often than not, you will be running the RPZ zones as a Slave of an external provider. In this case, the configuration is even simplier and all you need is to define the response-policy inside the main options (or a custom view) and set the zone to slave with the right master IP Address:

response-policy { zone "malicious-domains.rpz"; } break-dnssec yes qname-wait-recurse no max-policy-ttl 7200;
..
zone "malicious-domains.rpz"{
  type slave;
  masters { 1.2.3.4; };
  file "/etc/bind/malicious-domains.rpz";
};

And that's it. There are multiple providers that offer RPZ feeds, including SpamHaus and our own, CleanBrowsing. For more information, please inquire with sales@cleanbrowsing.org.