Using a Response Policy Zone with malwaredomains

The lovely people at RiskAnalytics provide lists of domains known to serve malware at http://www.malwaredomains.com/. It makes these available in several formats including DNS zone files. They don’t even charge for the service which is, frankly, awesome!

Many people configure their DNS servers so that they spoof the zone for each domain such that traffic is redirected to 127.0.0.1 (i.e. your own machine). This effectively stops hosts on that network from connecting to those zones and downloading unpleasant stuff. However, if you’re running a local webserver, say for development purposes, things can get confusing very quickly!

An alternative is using a DNS Response Policy Zone. This requires BIND version 9.8 or greater (or another DNS server that supports RPZ). RPZs are much more flexible than the approach above because they give us finer control over what we want the DNS server to tell the client. I have taken the approach that returning NXDOMAIN is the cleanest way of blocking traffic to these domains because a web browser will immediately give up on receiving that response. There’s no need to worry that a local webserver might interfere with domain blocking.

What’s an RPZ?

An RPZ isn’t a real DNS zone, but it look a lot like one. Each record in the zone tells the nameserver how to handle requests for certain domains and, most usefully for our purposes, to return a fake NXDOMAIN response. For example, if our RPZ contains—

*.this-is-your-bank-honest-guv.xyz  CNAME .
this-is-your-bank-honest-guv.xyz    CNAME .

then the nameserver won’t bother doing any lookups for the domain: it’ll just return NXDOMAIN for it and its subdomains.

I already have an RPZ with records to stop my television phoning home and to curtail Windows 10’s telemetry. I needed a script to merge the two into an RPZ that I could run on my resolver, so that’s exactly what I wrote!

How to do it

Assuming you already have a local resolver that serves your network, it’s a few simple steps to get this working:

1. Get my script from Github and put it somewhere appropriate.
2. Change the variables at the top. In particular you’ll want to make sure that the RPZ zone name and filename are appropriate for your environment.
3. Run the script and look at the output file (given by MY_RPZ_ZONE). It’ll try to run named-checkzone over the file to make sure it looks right, but you probably want to check that the output makes sense.
4. If you’re happy and you know it, add this stanza to your named.conf (or named.conf.local on Debian-ish systems), obviously changing CHANGEME appropriately:

   zone "rpz.CHANGEME" {
           type master;
           file "/etc/bind/db.rpz.CHANGEME";
   };

5. Reload your nameserver and try resolving one of the domains in the RPZ. You should get an immediate NXDOMAIN.
6. Optionally add a cron job to run this script every so often.

Enjoy 🙂