/ Domain Name System

Build a Privacy-respecting and Threat-blocking DNS Server

DNS blackholing can be a powerful technique for blocking malware, ransomware and phishing on your home network. Although numerous public DNS services boast threat-blocking features, these providers cannot guarantee you total privacy. The following article shows how you can build your private DNS server and add threat-blocking capabilities by using DNS Response Policy Zones (RPZ).

In our previous piece, we showed how you could add additional feeds to your Pi-hole for malware and phishing blocking. You can also use third-party DNS servers (e.g. OpenDNS, Norton ConnectSafe) for their threat-blocking features. We encourage to use both of these techniques, but you should be aware of their limitations.

Delay and Privacy Issues

The first problem of Pi-hole feeds is the reaction time. The latest WebRoot Threat Report suggests that "84% of all phishing sites last less than 24 hours". In other words, the faster a website gets on the blocklist, the better. Sadly, the Pi-hole blocklists are updated once a week by default. Although you can change the update frequency, it is still far from real-time blocking. Many of the lists are community maintained with unoffical targets of monthly updates.

The other issue is privacy. If you are forwarding your DNS requests to a third-party company, you are essentially giving away your web browsing history. Good privacy policies will not protect you and your data. Even if the company champions good privacy practices, a change in the management or a warrant can break those promises in the blink of an eye.

DNS-based Domain Blocking

A private DNS server can be a solution to both of these concerns. First of all, you can host a private DNS server in your favourite datacentre. Secondly, you can block DNS queries requesting malicious domains with the Response Policy Zone (RPZ) feature.

DNS RPZ Diagram

As for the privacy concerns, as the operation of the DNS server is under your control, you can configure what queries to log and when. Also, DNS resolution happens on your private server, so no third-party has access to the queries being submitted.[1]

As for the threat-blocking capabilities, you can add an overlay with Response Policy Zones (RPZ). This feature is simple: your DNS server can override DNS query responses when the domain in question is on the blocklist. RPZs are currently supported by BIND9, PowerDNS and a few other commercial products. For a detailed explanation of RPZs, please read these articles.

A further advantage of the RPZ feature is simplicity and agility. Firstly, the reputation feeds are pulled from the remote sources with standard DNS zone file transfers. There is no need to convert the blocklists into another format. Secondly, new domains on the remote blocklist are promptly pushed to your DNS server. The remote server emits a standard NOTIFY message, which triggers your private server to download the changes and apply them immediately.

DNS Resolver Build Instructions

We suggest picking a hosting provider close to your physical location to keep the DNS resolution snappy. What you will need:

  • a physical or virtual server
  • at least 2 GB of memory (4 GB is preferred)
  • Ubuntu 16.04 LTS
  • a fixed IP address
  • familiarity with SSH and the command line

The first step is spinning up a new instance running Ubuntu, and installing the necessary packages:

# apt-get update && apt-get dist-upgrade
# apt-get install bind9

As reputation feeds can be 50-150 megabytes large, BIND tends to eat up that sweet-sweet memory. So, to prevent the kernel killing the BIND process when the system is running out of memory, we suggest setting up a swap file.

# fallocate -l 2G /swap.img
# chmod 600 /swap.img
# mkswap /swap.img
# swapon /swap.img
# echo '/swap.img none  swap  sw 0  0' >> /etc/fstab

That was easy! Now we shall move on to the actual configuration part.

Warning: In our example, we are adding the data feeds from SURBL. Please note that if you copy-paste the settings below, the zone transfer will NOT work. You will need to subscribe to the data feed at SURBL and ask their customer service to whitelist the IP address of your DNS server. Read more about the availability of data feeds after the configuration section.

Replace the contents of /etc/bind/named.conf.options with the following settings:

acl goodclients {
        localhost;
        localnets;
        1.2.3.4;  # Replace this with your home IP address
};

options {
	directory "/var/cache/bind";
	max-cache-size 10m;
	cleaning-interval 30;
	max-cache-ttl 3600;
	max-ncache-ttl 3600;

	allow-query { goodclients; };
	allow-recursion { goodclients; };
	allow-query-cache { goodclients; };
	allow-transfer { none; };
	allow-update { none; };

	version "none";
	recursion yes;
	
	auth-nxdomain no;
	listen-on-v6 { none; };

	response-policy {
		zone "rpz.mw.surbl.org";
		zone "rpz.ph.surbl.org";
		zone "rpz.cr.surbl.org";
		zone "rpz.abuse.surbl.org";
	} qname-wait-recurse no;
};

To secure against DNS amplification attacks, your DNS server will only respond to the clients specified under the goodclients section. Therefore, you have to replace 1.2.3.4 with the public IP address of your home network (use whatismyip.com or this search to find out what your IP is).

As for blocking, the magic happens in the response-policy section. We tell BIND here to override the DNS responses in case a domain features in one of the SURBL zone files.

We are not ready yet. Save the file and now create a new file named /etc/bind/named.conf.surbl, and add the following:

zone "rpz.mw.surbl.org" {
        type slave;
        masters { 94.228.131.210; 94.228.131.211; };
        file "/var/cache/bind/rpz.mw.surbl.org";
        allow-query { goodclients; };
};

zone "rpz.ph.surbl.org" {
        type slave;
        masters { 94.228.131.210; 94.228.131.211; };
        file "/var/cache/bind/rpz.ph.surbl.org";
        allow-query { goodclients; };
};

zone "rpz.cr.surbl.org" {
        type slave;
        masters { 94.228.131.210; 94.228.131.211; };
        file "/var/cache/bind/rpz.cr.surbl.org";
        allow-query { goodclients; };
};

zone "rpz.abuse.surbl.org" {
        type slave;
        masters { 94.228.131.210; 94.228.131.211; };
        file "/var/cache/bind/rpz.abuse.surbl.org";
        allow-query { goodclients; };
};

In this file, we specify where our DNS server can download the reputation feeds from: 94.228.131.210 and 94.228.131.211. Note: These two IP addresses belong to SURBL and you need a subscription.

Finally, edit /etc/bind/named.conf and append the following to the end:

include "/etc/bind/named.conf.surbl";

Restart your DNS server to apply the new changes:

# systemctl restart bind9

If everything has been configured properly, you should see messages in /var/log/syslog similar to:

Dec  3 12:00:26 myserver named[1196]: transfer of 'rpz.abuse.surbl.org/IN' from 94.228.131.210#53: connected using 172.12.34.52#51172
Dec  3 12:00:26 myserver named[1196]: zone rpz.abuse.surbl.org/IN: transferred serial 1512302336

Debugging

If something does not work, the first thing you should check is whether you are allowed to retrieve the remote feeds from SURBL:

$ dig AXFR @94.228.131.210 rpz.cr.surbl.org

The command above should retrieve a lengthy list of domains from the cr blocklist.

To verify whether domain blackholing is operating correctly, run the following command on your DNS server:

$ dig @127.0.0.1 test.cr.surbl.org

Your DNS server should respond with status: NXDOMAIN in the ->>HEADER<<- section and ADDITIONAL SECTION should feature SOA dev.null. zone.surbl.org..

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 test.cr.surbl.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37220
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.cr.surbl.org.		IN	A

;; ADDITIONAL SECTION:
rpz.cr.surbl.org.	180	IN	SOA	dev.null. zone.surbl.org. 1512301442 180 180 604800 180

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 03 12:07:13 UTC 2017
;; MSG SIZE  rcvd: 99

If one of these is failing, check your configuration files and event log again.

So Which Blocklist Should I Use?

So the million dollar question: which blocklist should I use? There are a few providers on the market. Luckily, we did a little investigation, so you do not have to.

The following providers offer reputation feeds via DNS zone transfers:

The overall experience with these feed providers is mixed. Even though we found good-quality feeds, almost every single company is only targeting the commercial market. Unfortunately, this either makes the purchase difficult or expensive for a home user.

Our first pick was DissectCyber, as this company seemed to target home users as well. Alas, we found a very unusual sign-up process and the control panel was just way too confusing. Secondly, we could not figure out where the reputation data was coming from, so we had some doubts with regards to the quality of the feeds. We gave up after a few failed registration attempts and moved on to the other providers.

We contacted Farsight Security then.[2] Their blocklist revolves around the Newly Observed Domains (NOD) concept, based on the idea that emerging threats are hosted on new domains (e.g. someone registers pay-pal.com for hosting a phishing site). Unfortunately, the subscription fee costs an arm and a leg (i.e. thousands of US dollars), so Farsight is not an option for home users. On a related note, the customer rep tipped me off that Brian Krebs is also a Farsight user, and researchers may get access to the feeds for free under the company's grant programme.

Our next try was Infoblox, which did not seem to offer any RPZ feeds on a subscription basis. We suspect the Infoblox feeds are available to their customers only. We also tried to request access to the SWITCH feeds. One of the customer reps got back to us, but once the agent learned that we are a not-for-profit, his emails stopped coming. As for ThreatStop, the company did not bother to respond.

Malware Patrol offers their feeds in multiple formats, including zone transfers. The pricing seemed to be appealing at first: the premium feeds cost U$3.59/month. We subscribed to the premium package, but we quickly found out that the feeds are only available in a zipped format. It turned out zone transfers come with the commercial (and more expensive) subscriptions only.

We had high hopes for the Spamhaus feed, as their DNSBL service is one of the best when it comes to Spam filtering. Spamhaus offers a feed called 'DROP' (Don't Route Or Peer Lists) for free, but we did not find it that useful. The real thing is what they call the 'Standard group' with a price tag of U$250/year. We were a bit disappointed here, as the subscription may be a sensible investment for small businesses, but probably not for a home user.

Strongarm, on the other hand, targets home-users. Although the free personal subscription does not include the RPZ feeds, the U$3/user/month Business package does. This offer sounds like a fair deal.

We got hold of a free trial from SURBL. We were impressed by the quality of the feeds, as they are curated from a handful of open-source and commercial sources. New domains are pushed out as delta updates every 10-15 minutes. Quite surprisingly, the latest additions to the hpHosts phishing and malware feed are quickly blocked by SURBL, too. We were also satisfied with the technical support team, who helped us set up the service in no time. However, the disappointing thing, again, was the sales team at SecurityZones (SURBL sells the subscription via third-parties). The team just got back to us this morning with a few follow up questions and a quote, weeks after our initial request.

In summary, Strongarm seems to be the strongest contender from the pack. We found both its customer service and the price tag home-user friendly. The second and third place go to SURBL and Spamhaus for the perceived level of quality, but their customer service was somewhat disappointing.

Summary

So, does a private DNS server worth all this hassle? Maybe, it depends on your preferences and your budget.

As for the malware blocking and anti-phishing capabilities, providers of threat data are not ready for serving the end-user market. The pricing is too expensive, and the companies are not dealing with individual subscribers. We hope these feeds will be reasonably priced for the home-user market.

Until then, one potential option to overcome the obstacles is pooling up. For example, the $250/year Spamhaus feed allows the protection of maximum 350 users. If a group of friends can subscribe to Spotify Family family, why they do not spend a few dollars each on threat protection? As for alternative feeds, Strongarm probably worth the small investment (U$3/user/month), but we would prefer the more enterprise-grade feeds (if they were available) from SURBL and Spamhaus. If you do not mind retrieving blocklists in a different format and converting them, you may want to look into the zipped Malware Patrol feeds.

If your top priority is privacy, however, you should run your private DNS server. As a side effect, your DNS server will validate DNSSEC signatures. To hide and secure traffic between the DNS server and the clients, we would undoubtedly add DNSCRYPT to the equation as well.

What are your thoughts? Who is your preferred threat-feed provider? How do you block threats on your home network? Let us know on Twitter at @CryptoAUSTRALIA.

Image courtesy of Pixabay


  1. Except your hosting provider ↩︎

  2. Fun fact: the man behind the DNS RPZ standard works for Farsight Security ↩︎

Gabor Szathmari

Gabor Szathmari

Gabor is a passionate privacy, open government and free speech advocate. He is helping organisations with their information security challenges in his professional life.

Read More