I recently setup Pi-hole on an existing Raspberry Pi running CentOS on my home network to serve as my DNS server and block advertising and unwanted domains for all internet-connected devices. I’m still using an ASUS router with Shibby Tomato firmware for routing, DHCP and private VLANs so I had to make a few changes. This is how I got up and running along with some performance tuning.
Pi-hole is a set of software packages that provide filtering and advertisement blocking for all internet services on your network. It alleviates what might traditionally be done via adblockers or per-device software because it blocks things at the DNS level. It uses dnsmasq, lighttpd, FTL and some other packages to tie all this together into a nice, easy-to-use web interface. Pi-hole can be installed on any existing Linux device or VM.
Pi-hole utilises several well known and trusted internet blacklists and keeps them up-to-date. At the DNS level it can then thwart unwanted ads, malware domains and other unsavoury internet denizens from appearing on any of your internet devices or computers.
This video gives a decent overview.
How It Works
You can have pi-hole handle your DNS, DHCP or both. On the LAN side it uses dnsmasq as a caching DNS server where filtering/discarding happens. Upstream lookups are performed by choosing one of the several free options like Google DNS, OpenDNS, Level3 and others or you can enter your own.
For my purposes I wanted Pi-hole to perform bare-minimum caching DNS duties as my Tomato router does a good enough job of handling DHCP and address assignment. I am also using private, isolated VLANs for devices that are less than trustworthy like Smart TVs.
Getting Started – My Network
I am running pi-hole on an existing Raspberry Pi for DNS services, but this could be any host or VM inside your network. I have DHCP services handled by my router. Once setup I just needed to point static DNS from my Tomato router to use the new pi-hole service.
I am going to assume you’re using a Linux-based device like a Raspberry Pi running on CentOS but any VM or host will work. The official instructions tell you to curl a script and pipe it to bash as root but we’re not going to do that.
Install Git and EPEL Repository for ARM
yum install git -y
Next, ensure you have the EPEL repository installed. On ARM devices like the Raspberry Pi you can use the snippet below to enable it.
cat > /etc/yum.repos.d/epel.repo << EOF [epel] name=Epel rebuild for armhfp baseurl=https://armv7.dev.centos.org/repodir/epel-pass-1/ enabled=1 gpgcheck=0 EOF
Now you’re ready to clone pi-hole and run the automated installation script.
Clone and Run the Installation Script
git clone --depth 1 https://github.com/pi-hole/pi-hole.git Pi-hole cd "Pi-hole/automated install/" sudo bash basic-install.sh
The automated installation script will now execute.
After any missing packages are installed it will setup and configure itself and you’ll be presented with configuration details.
You’ll then be presented with an ncurses configuration guide, the defaults are just fine.
At this point you should be able to access http://your-pi-hole-machine/admin/index.php to access the web interface. Be sure to copy the web GUI admin password printed on the screen and keep it somewhere safe. You may need to manage your own firewall rules here, so make sure that UDP/53 (DNS) and TCP/80 (HTTP) are open on your Pi-hole host.
Limit Writes to Solid State Devices
It’s recommended to lower the DBINTERVAL setting for the FTL service from the default of 1second to 60 seconds to limit the frequency of database writes. This should prolong the life of your SD, SSD, M2, or similar solid state device if you’re using one.
cat > /etc/pihole/pihole-FTL.conf << EOF # Lower DB writes for SD card life to 60 # https://wiki.archlinux.org/index.php/Pi-hole#FTL DBINTERVAL=60 EOF
Now restart the FTL service to take effect.
systemctl restart pihole-FTL
Tuning dnsmasq for Higher Traffic
Before you point your router or clients to start using pi-hole for your DNS you may want to tune settings for more demanding networks or a larger amount of clients. I added the following to my /etc/dnsmasq.d/02-custom-settings.conf.
cat > /etc/dnsmasq.d/02-custom-settings.conf << EOF #### EDIT SETTINGS dns-forward-max=5096 min-cache-ttl=300 rebind-domain-ok=/plex.direct/ addn-hosts=/etc/hosts.mydomain #### END EDIT EOF
Let me explain these above:
- dns-forward-max = this increases the max DNS forward limit, if you have a rather busy internal network you will easily hit the limit of 150 which in my opinion is way too low. 1024+ is more realistic.
- min-cache-ttl = This extends the minimum time-to-live settings for cached lookups and ensures all DNS lookups will be cached for at least 300 seconds. This is a very useful setting and lets you take full advantage of caching nameserver capabilities.
- addn-hosts = this is a file containing my own /etc/hosts type entry of local hostnames for easy local LAN resolution. Pi-hole also provides /etc/pihole/local.list for this purpose too if you’d rather use that.
- rebind-domain-ok = this lets you specify domains where DNS rebind support is needed like the Plex Media Server. If this doesn’t mean anything to you then you probably don’t need it.
Apply the new tunings by restarting the dnsmasq service.
systemctl restart dnsmasq
Test DNS resolution on another system in your network, you should quickly get responses back from dig requests
dig @192.168.0.98 hobo.house
If all is clear now it’s time move your DNS to pi-hole. If you specify DNS servers for each of your clients then you just need to update them to point to your newly setup device.
At this point you’re done, skip past the Tomato section if this doesn’t apply to you for Pi-hole usage, common commands and useful tips.
Pointing your ASUS Tomato Router to Pi-Hole for DNS
I am using an ASUS Black Knight router running the Shibby Tomato firmware, which I will use for demonstration purposes.
First I need to point it to use my new pi-hole DNS (192.168.0.98 in my case)
Next, I need to turn off the existing DNS settings that Shibby Tomato previously managed for me.
Additionally you might need these settings for dnsmasq.conf within Tomato to ensure that all wireless clients obtain Pi-hole DNS via Tomato DHCP if you see (forwarded) in query logs.
If you see the following in Pi-hole query logs then you need to set the below setting
Besides setting the below dnsmasq Tomato settings I also enabled the two SLAAC and DHCP IPv6 options below.
Here are the dnsmasq lines for easy copy/paste, you should substitute my 192.168.0.98 for your Pi-hole address.
server=192.168.0.98 dns-forward-max=5096 min-cache-ttl=600 dhcp-option=6,192.168.0.98
Lastly I need to add a static route for any private, isolated VLANS I am managing with Tomato Shibby. In my case I was using 172.16.0 for my private VLAN but I use 192.168.0 networks for everything else. This is needed to allow DNS traffic between the normally-isolated networks. You can disregard this step if you don’t have such a setup.
Without the static route I would never be able to route 172.16.0 –> 192.168.0.98 (Pi-hole) for DNS traffic.
Testing and Using Pi-Hole
At this point clients in your home network, including all wireless clients should be immediately benefiting from the ad, malware and bad-people-on-the-internet filtering provided by pi-hole. You can access the web UI and note stats, percentage of traffic , statistics per client, blocks, common domains and other useful information.
Note that the Percent Blocked are DNS queries to/from undesirable locations like known advertising, beacons, trackers which would normally denote some level of accompanying network traffic – it’s not actual network traffic blocked.
For reference these are the DNS settings I have set in the UI. You can just as easily manage these in /etc/dnsmasq.d/01-pihole.conf via SSH and restarting the dnsmasq service.
I have opted for listening/permitting all origin traffic as my Pi-hole is firewalled behind my Tomato router and I need to accept multi-hop origin requests from private VLANs from within my network. Most people can use “Listen only on interface eth0” for example.
There are also options for blacklisting and whitelisting domains, you can access this in the UI settings.
You can run the supplied pihole script to update it over SSH – this will update the core version if there is an update available.
Pi-hole already sets up a cron job in /etc/cron.d/pihole however which updates the ad sources once a week, the above is just for updating the released version. You can also run this inside the web interface.
You can also issue common commands as needed via SSH, check pihole -h for more info.
pihole -b unwantedsalescrap.net moreunwantedjunk.com
White listing domain(s)
pihole -w myfriendsblogthing.org thisotherblog.net
Blacklisting wildcard domains, e.g. any url and associated subdomains.
This is for single domains only.
pihole -wild reallyirritatingmarketing.com badpeople.org
Querying the ad lists domains. You can also pass -exact to match more precisely.
pihole -q domain.match.here
Changing the web admin password. If you leave the new password blank it will simply not prompt for one.
pihole -a -p
Pi-hole also comes with a nice top-like chronometer utility
Adding More Block Lists
While you can use either the pihole -b (blacklist) or pihole -wild (wildcard domain block) for blocking single domains the most efficient way to protect your network is through domain block lists.
Domain block lists are cultivated 3rd party lists that contain many many domains that are known to be malicious or contain unwanted advertising and trackers. When you add block lists your pi-hole will query them and keep your block lists updated via cron.
I’ve found a great source of additional block lists over at the cryptoaustralia.org blog as well as wally3k. You can easily add/manage block lists in the web UI under Settings -> Block Lists. Enter each block list one at a time and hit save, click save and update when you are finished and it will regenerate.
You can also manage them via the CLI by adding entries new sources to 3rd party blocklists in /etc/pihole/adlists.list and then tell pi-hole about it.
Here are the additional 3rd party block lists I am using, they’ve worked for me with no issues and block around 555,000 domains. Out of the box Pi-hole should block around 123,000 domains as of typing this.
https://hosts-file.net/exp.txthttps://hosts-file.net/emd.txt https://hosts-file.net/psh.txthttps://v.firebog.net/hosts/Airelle-hrsk.txt https://v.firebog.net/hosts/Shalla-mal.txt https://ransomwaretracker.abuse.ch/downloads/RW_DOMBL.txt https://ransomwaretracker.abuse.ch/downloads/LY_C2_DOMBL.txt https://ransomwaretracker.abuse.ch/downloads/CW_C2_DOMBL.txt https://ransomwaretracker.abuse.ch/downloads/TC_C2_DOMBL.txt https://ransomwaretracker.abuse.ch/downloads/TL_C2_DOMBL.txt http://www.networksec.org/grabbho/block.txt https://isc.sans.edu/feeds/suspiciousdomains_Medium.txt http://someonewhocares.org/hosts/hosts https://s3.amazonaws.com/lists.disconnect.me/simple_malvertising.txt http://www.joewein.net/dl/bl/dom-bl.txt https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/win10/spy.txt https://v.firebog.net/hosts/static/SamsungSmart.txt https://gist.githubusercontent.com/anudeepND/adac7982307fec6ee23605e281a57f1a/raw/5b8582b906a9497624c3f3187a49ebc23a9cf2fb/Test.txt https://raw.githubusercontent.com/StevenBlack/hosts/master/data/KADhosts/hosts https://reddestdream.github.io/Projects/MinimalHosts/etc/MinimalHostsBlocker/minimalhosts https://raw.githubusercontent.com/StevenBlack/hosts/master/data/add.Spam/hosts https://v.firebog.net/hosts/static/w3kbl.txt
You may want to keep an eye on your DNS queries the first 24hours or so to make sure you’re not blocking any false positives. You can unblock/whitelist domains with the pihole CLI (it’s reported doing this via the UI doesn’t always work currently).
There were a few I had to white list for example:
pihole -w youtu.be opensubtitles.org www.opensubtitles.org
Right away I saw an increase in general responsiveness across all my devices, most likely due to the caching name server settings. I expect a further increase in responsiveness soon due to blocking many of the known advertising sources. The graphing, logging and dashboard information is easy to read and inspect.
I really like the idea of this project and how it ties everything together. Ad-blocking using 3rd party block lists isn’t a new concept but packaging this into an easy-to-use solution that works on any existing machine using OSS tools is really useful.
In upcoming versions the FTLDNS or “Faster than Light DNS” should make an appearance which adds more direct hooks into dnsmasq and speed things up even more from a user perspective, though it’s already pretty snappy.
Performance and Usage
A few hours after implementing Pi-hole around 10% of the DNS lookups on my home network showed to be attempts by advertisements, trackers and other undesirables, this is now curbed. I even managed to blacklist some additional domains from China (baidu.com) I noticed in the query log that I’m not sure had any reason to be talking to my network. It is also very lightweight to run, consuming around 9mb of memory and a very nominal amount of CPU on the Raspberry Pi2 and CentOS7.
Whitelisting not Working via Web UI
As of Pi-hole 3.3 there are some known issues with whitelisting domains via the web interface, the workaround for this is to remove the whitelist via the web interface and re-add it via pihole -w domain.name.here. This does not affect all users, only some due to a locale issue and should be fixed soon. This did not affect me on CentOS7 / Raspberry Pi2 in the GMT timezone.
Statistics 24 Hours after Install
After 24hours I started to see the real DNS blocking imprint with 20-some-odd devices on my home network, a few friends over contributing to the fray and a full day of working remotely. I also added a dozen more block lists to the mix, pushing my block domains up to around 555,000.
Upwards of 22% of the DNS lookups were blocked which normally would have incurred some additional traffic overhead. CPU and memory usage stayed about the same, it’s pretty lightweight. General device network responsiveness to queries continued to be snappier than they were before it was deployed.