I’ve been thinking a bit about Response Policy Zones in BIND lately, and I thought I’d revisit the feature. While I’m at it, call the functionality whatever you like but don’t call it a DNS firewall: that is a ridiculous term.

DNS Response Policy Zones specify policy information in a specially crafted DNS zone. You typically have one or more producers of so-called reputation data who publish one or more zones which are used by consumers of the data. Publishers create a zone, maintain it with, say, dynamic DNS updates, and offer it via zone transfer (AXFR/IXFR) to their consumers. You and I can be producers if we wish to record reputation data for consumption within our organization (or give it to others to consume), but there are also producers who have data for the world at large. One example is Spamhaus with its DBL RPZ.

When correctly configured in a BIND recursive resolver, RPZ is a bit like what a DNSBL is to e-mail. Where the latter defines a policy whether or not to accept a particular message, the former allows operators of recursive DNS servers (e.g. servers running at your ISP or in your corporate environment) to rewrite answers returned by authoritative DNS servers. In order to be able to do that, we configure BIND to use one or more RPZ zones. From this moment onwards, BIND queries these locally available zones (remember: zones are either local to start with, or BIND has slaved them) in a specified order, and it doesn’t need to consult the public DNS for each check. This is in stark contrast to how an e-mail server (MTA) queries a DNSBL, which it does for each and every incoming message.

RPZ offers some interesting features, including:

• Enterprise administrators can effectively and very quickly add specific malicious sites to their own RPZ zone using dynamic updates, and therefore black out a site completely.
• We can block or redirect queries for malware sites (think: ensure infected computers on your site accessing external URLs) and sub-domains.
• Catch queries for particular domains and direct them to a walled garden.
• Block or redirect DNS replies which contain a specific set of IP addresses.

RPZ is triggered by queries on a particular domain name, or if

• The answer to a query is in a particular net block.
• The answer is from a specific name server.
• A name server response is in a particular address block.

RPZ gives me a very fine-grained control over which responses my BIND server changes. Say I have a DNS block list I obtain from a foreign producer: I would usually use its content in an all-or-nothing fashion, however I can easily prepend a zone to my existing RPZ configuration which allows me to white-list individual records. In the following configuration, RPZ will first test the rpz-white zone and then the rpz-foreign zone. If the former contains a matching record, the PASSTHRU policy causes records to act as if they are CNAME records which target the originally requested name. In other words, this policy protects responses from being changed.

response-policy { 
   zone "rpz-white" policy PASSTHRU; // my own white list
   zone "rpz-foreign";	// obtained from producer
};

For example, suppose the rpz-foreign list contains an entry www.playboy.com A 127.1.1.0: this entry will cause BIND to return the specified address for each A record query of the name. If I add a record to my very-own rpz-white policy, I can override (ensure the redirect doesn’t happen) that response. In the following example, I query the name, perform a dynamic update on my policy zone, and re-query.

$ dig +noall +answer @127.0.0.1 www.playboy.com
www.playboy.com.   60   IN   A   127.1.1.0

$ nsupdate
> server 127.0.0.1
> zone rpz-white
> update add www.playboy.com.rpz-white. 60 CNAME .
> send
> quit

$ dig +noall +answer @127.0.0.1 www.playboy.com
www.playboy.com.   600   IN   A   216.163.137.68   ; "real" public address

Blindly configuring BIND to consume a producer’s data is dangerous, as the producer then basically defines what your DNS clients can see, but this is the same kind of advice or warning I’d give you if you configure your mail server to “consume” a DNS black-list. RPZ used carefully within an organization’s boundaries, can make BIND very versatile.

If you’re interested in a few more details on RPZ, I suggest you watch Barry Green’s webinar, in which he focuses on blocking malware with the help of RPZ.