If you're reading this article (and indeed this magazine), you're probably not a huge fan of spam/malware/crapware/spyware, and so on. However, because you're also probably running Linux, you can avoid most of that, right? Just keep the system up to date, install AdBlock, apply SpamAssassin to your email, and so on – easy peasy lemon squeezy.

But, what happens if you have a device that doesn't support AdBlock or antivirus software (e.g., some of the more locked down Android devices)? Or, if you want to block certain domains or networks completely? Firewalling based on IP addresses is great, and you can even find country lists; however, that won't help you block attackers that quickly bounce their domain around multiple providers. If only there were a way to firewall stuff easily at the DNS level.

Response Policy Zones

Back in 2011, ISC, the company that produces BIND and DHCPD, decided this was a problem they wanted to address, so they rather cleverly added RPZ (Response Policy Zone) [1] support in a way that requires no changes to existing DNS client software or to other servers making use of the RPZ server. Basically, RPZ lets you define records to which that the response policy will be applied. These records can be the domain name being queried (QNAME), the IP address being returned in response to the query (IP), the name or domain of any DNS server used to fulfill a query (NSDNAME), and the IP address of any DNS server used to fulfill a query (NSIP).

This means you can, for example, filter all requests for *.example.org, any query that would result in an answer of 10.0.0.0/8, or any query that would use the DNS server evil.example.org or a DNS server on the evil network 192.168.0.0/16. You're not just limited to blocking queries either, you also can return NXDOMAIN (no such domain) records for a query or NODATA (no records for that query). You also can reply to a query with an arbitrary response (Local Data Action), or you can choose to allow the query (PASSTHROUGH) [2]. Note that allowing a query instead of blocking it can be useful, because this lets you configure your RPZ to allow queries for good.example.org and block all other queries for *.example.org.

Forcing Use of Your RPZ Server

The first step is to force clients to use your RPZ server. This step is important because a lot of malware will hijack the DNS settings on a client to point them at an attacker-controlled server. The easiest way to do this is set up one or more DNS servers running RPZ and then firewall your network so that only they are allowed to make outgoing DNS queries (Listing 1).

In this setup, make sure you block both TCP and UDP outgoing to port 53. Please note that clients using VPN software, Tor, and the like will be able to bypass this restriction, so DNS firewalling (like any firewalling) isn't 100 percent foolproof when it comes to VPNs.

Configuring RPZ

This is the easy part: In named.conf, in the options section, simply put:

response-policy { zone "rpz.example.org";};

Then, define the zone file,

zone "rpz.example.org" {
  type master;
  file "/var/named/rpz.example.org.zone";
};

and configure the zone file (Listing 2). Note that there is no $ORIGIN specification.

This listing specifies that any queries to evil-domain.com or records and subdomains within it will be served an NXDOMAIN response.