Protect your network with DNS Firewall


If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.

Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.

Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.

(Illustration Christoph Frei)
(Illustration Christoph Frei)


With RPZ, you not only get a technology to filter malicious domain name resolution on your own, but you can also subscribe to RPZ feeds from third parties. An RPZ zone is based on a normal DNS zone and takes advantage of the zone transfer protocol to propagate updates immediately and with minimal bandwidth consumption.

SWITCH has been using RPZ within its organisation for over a year. The positive results and our experience with the technology have led us to believe that this technology is of great value to our customers as well. The solution we have come up with is a package we call DNSfirewall. We have evaluated third-party RPZ feeds but also decided to implement our own RPZ zones. The focus of both the third-party RPZ zones and our own is on malicious domain names (e.g. malware or phishing).

The SWITCH RPZ zone is supplied to our customer and installed on their recursive name server. Malicious domain names within the RPZ zone are answered in accordance with the local operators policy (in this example, they are blocked). Log hits are sent back to SWITCH so that we can inform the security contacts of the most likely infections as appropriate (depending on the domain name).
The SWITCH RPZ zone is supplied to our customer and installed on their recursive name server. Malicious domain names within the RPZ zone are answered in accordance with the local operators policy (in this example, they are blocked). Log hits are sent back to SWITCH so that we can inform the security contacts of the most likely infections as appropriate (depending on the domain name).

A unique property of the DNSfirewall solution is that we ask our customers to send us hits of malicious domain lookups. We use this information to notify the security contacts for these IP address ranges of the most likely infections as appropriate. For example, we would typically send out such a notification in case of domain lookups to malicious Domain Generation Algorithm (DGA) domains. A lot of malware makes use of such DGAs. We currently cover over 15 malware families with DGA domain names. For our RPZ zones, we implement the “log-only” policy whenever possible. SWITCH is a strong believer in an open and free Internet. Every solution, whether it is e-mail filtering or DNSfirewall, can limit this openness. Therefore, we try to use this technology as carefully as possible. Just blocking the name resolution of a DGA domain does not prevent computers from being infected. Typically, a computer requesting that such a domain name be resolved is in fact already infected. Therefore, a notification to the security contact is essential and part of our job as a CERT anyway. This example shows that, even if we implement a log-only strategy for some domain names, this alone can prove highly valuable.

Another use case is phishing URLs. We get a lot of very localised phishing e-mail reports from our community. We are now in the process of feeding phishing domain names into our RPZ zones as well. We treat phishing domain names a little bit differently. First, all phishing reports are checked by our incident handler. If they are of valid concern, the domain name is fed into our RPZ zone. Name resolutions for phishing domain names are typically redirected to our landing page, where we inform the user of the blocking. In case of a false positive, this page also allows the user to send us feedback.

Any domain name we add to our RPZ zones is only added for a specific period of time. Phishing URLs are irrelevant after a few days, a DGA domain in many cases after just one day. In addition, any policy we implement in our RPZ zone can be overruled by our customers.

Next to ISC BIND itself, I am aware that Infoblox appliances support RPZ zones. Regardless of whether you are a customer of ours or you get your RPZ zone from other sources, I believe RPZ is a great technology to protect your network from “bad ware”. For further information on RPZ, I suggest the following resources:

More info about the SWITCH DNS Firewall service can be found at https://switch.ch/dnsfirewall