RPZ Shenanigans

Now that you have RPZ working, what can you do with it? If you want to block entire domains (e.g., ad networks and malware networks), your best bet is to reply with NXDOMAIN. However, if you want to be a bit more selective and only block certain hosts, I suggest using NODATA (e.g., to just block ads.example.org but leave the rest of example.org unaffected). You can also use a whitelist approach – using passthrough for trusted hosts and blocking everything else within that domain.

A fourth option is the "Local Data Action." This approach allows you to create "walled gardens," so you can send clients asking for evil-domain.org to your own server (e.g., you-are-infected.example.org or even to evil-domain.org.you-are-infected.example.org).

This second option lets you preserve the data the client requested. Thus, if it's a web request for a malware site, you cannot only send clients to a server you control, which presumably has links to antivirus software, you can also take a specific action based on the domain they asked for.

Because of the way most bad guys operate, you can also prevent a lot of badness by blocking known "naughty" name servers. For example, if you find a domain being used for badness, you can block the name servers hosting it. Of course, you need to be careful here because the bad guys may be using DNS servers that also serve a lot of legitimate domains. The same goes for blocking IP addresses; quite often attackers will compromise a server and use it. In that case, blocking the entire network will effectively prevent spam and malware but also block a lot of legitimate sites.

Large-Scale RPZ

Some tips and tricks are useful in regard to large-scale RPZ, the first of which is that you can have multiple RPZ zones (e.g., one for spam, one for malware), and you can also use externally provided RPZ zones. A number of antispam and reputation firms use RPZ to share their data.

Also, if you have multiple servers, you'll want to keep the RPZ zones synchronized closely; otherwise, a client may request a record that would be blocked on server A but is allowed on server B (because the RPZ zone file is not yet synchronized). To avoid this situation, use also-notify in the RPZ zone definition to ensure any updates are propagated quickly.

RPZ Data Sources

Now that you can block DNS requests and any resulting network traffic, you'll want to add some data sources. Your two main choices are to find data and create your own RPZ files or to point at external sources directly.

I prefer creating my own RPZ, because this gives me control over what is being blocked and prevents information from leaking. Leaking, you say? By definition, for RPZ to work, you need to send the DNS query to the server hosting the RPZ zone. If you use an external RPZ server, then they will see all your DNS queries, except for those that you define in your own zones with PASSTHROUGH.

Some good sources of data include things called "list of malware host names" and "list of ad domains." Additionally, numerous law enforcement agencies have bulletins with lists of IPs being used by malware command and control systems or other malicious actors.