Response Policy Zones (RPZ)

Block Malware, Phishing, Ransomware Sites and Botnets

Most modern electronic crime and network abuse relies on the Domain Name System. Protection against these threats must include the Domain Name System.

This kind of firewall can also protect against internal threats coming from compromised devices. As users are taking their devices out of your controlled network, acquiring infections, and then bringing them back in, enterprises need to increase their vigilance.

A DNS firewall selectively intercepts DNS resolution for known-malicious network assets including domain names, IP addresses, and name servers. Interception can mean rewriting a DNS response to direct a web browser to a “walled garden,” or simply making the malicious network assets invisible and unreachable.

A DNS firewall can block:

Phishing - When a user clicks on a link in an email, for example from a fake banking site, you can intercept the lookup of that site.
Malware - When a user attempts to navigate to an IP address known to host malware, you can redirect them to a site of your own with instructions on scanning their computer.
Ransomware - Ransomware is a type of malware in which someone takes over assets on your network and blocks access to them until you pay a ransom. This is a rapidly growing threat.
Botnet command and control sites - When devices inside your network attempt to contact suspected botnet command central, you can drop the queries and log them for analysis and followup.
Identify infected machines - By analyzing the query logs, you can track down the machines in your network that are attempting to contact these abuse sites, and clean up any infections or botnet code.

DNS Reputation Data Providers

DNS Response Policy Zones (RPZ) was invented at ISC and first implemented in BIND, but it is an open and vendor-neutral standard for the interchange of DNS firewall configuration information.

Each of the vendors listed below offers proprietary data streams based on their own research. It is possible to subscribe to more than one data feed from a vendor, and to subscribe with multiple vendors.

The easiest way to assess the efficacy of one of these blocklists is to subscribe for a trial period, and see how many abuse queries are subsequently blocked.

Cloud services that use DNS Firewalls

For users who do not want to run their own DNS systems, there are numerous public cloud-based DNS services that include DNS firewalls, such as the examples below:

Here’s how to get started

Most RPZ data providers offer a free trial period. Sign up to try one or more data feeds from security experts Deteque, Farsight Security, SURBL or ThreatSTOP, or other public and private sources, based on your own needs and suspected threats.
Configure your BIND 9.9 or later server to receive updates to the RPZ zone from your chosen data providers using industry standard DNS mechanisms fully supported in BIND (IXFR/AXFR). ISC offers technical support contracts for BIND, or you are welcome to ask the BIND user community for help.
RPZ filters and policies in BIND are continuously updated with live threat intelligence data curated by the security data provider.
Add a white list locally for any blocked zones you want to unblock for your users.
Clients using your resolver will be blocked and redirected when they try to access malware and abuse sites before they can be infected or compromised.
Measure the effectiveness of your blocklist(s) by tracking the increase in responses that are dropped or redirected. Identify infected client machines based on the client IDs of machines making these queries.
After you SEE RESULTS of using the RPZ firewall in your own network decide whether you want to continue subscribing to the service.

ISC does not test, certify, or recommend specific RPZ vendors. RPZ data feeds from any of the vendors above should work with BIND.

Technical Details

The rules in a Response Policy Zone consist of triggers or filters that identify what responses to modify, and policy actions to apply to these responses. Each rule can use one of five policy triggers and specify one of eight policy actions.

Response Policy Triggers

by the query name. [QNAME]
by an address which would be present in a truthful response. [RPZ-IP]
by the name or address of an authoritative name server responsible for publishing the original response. [RPZ-NSDNAME and RPZ-NSIP]
by the IP address of the DNS client. [RPZ-CLIENT-IP]

Response Policy Actions

to synthesize a “domain does not exist” response. [NXDOMAIN]
to synthesize a “name exists but there are no records of the requested type” response. [NODATA]
to redirect the user via a CNAME to a walled garden. [CNAME example.org]
to replace the response with specified data. [Local Data]
to require the client to re-submit the query via TCP. [CNAME rpz-tcp-only]
to exempt the response from further policy processing. [DISABLED, CNAME rpz-passthru]
to drop the query, without any response to the client. [CNAME rpz-drop]

The most common use of a DNS firewall is to poison a domain name, IP address, name server name, or name server IP address. Poisoning is usually done by forcing a synthetic “domain does not exist” response. This means if you know a list of known “phishing” domains you could make these names unreachable by your customers or end users just by adding some firewall policy into your recursive DNS server, with a trigger for each known “phishing” domain, and an action in every case forcing a synthetic “domain does not exist” response. Or you could use a data replacement action such as answering for these known “phishing” domains with the name of a local web server that can display a warning page. Such a web server would be called a “walled garden.”