12 23 4
Personally, I’m not really against online marketing on websites in the form of ads. The problem comes when some websites abuse this practice, significantly slowing down page load time and consuming more hardware resources than it is supposed to. Also, I have privacy concerns regarding data that trackers collect about me and how they use it. This is actually a controversial subject as some argue that ads financially support free content, so I will leave it up to you to decide to implement the solution presented in this article or not.
In the following sections I will share my experience using a Network Ad Blocker to free all my home devices from website ads. As given in the title, I used a solution called Pi-hole for my technical implementation.
What is Pi-hole?
Pi-Hole is a ad blocking application designed to be used on private networks. It works as a DNS Sinkhole which blocks DNS requests for tracking and advertising domains. Below is a picture extracted from their website highlighting the Pi-Hole’s key features .
So, what happens when I switch from my Internet Service Provider’s (ISP) DNS to Pi-hole? Let’s have a look at the next picture as a generic example.
On the left side we have a standard configuration where the web page and its contents are resolved by a ISP’s DNS. When we introduce Pi-hole to this configuration, the request for ads is intercepted and prevented from being downloaded.
One of the main advantages of Pi-hole over traditional ad blockers (ones that download ads but don’t present on screen) is that it prevents the device from communicating with ad servers, reducing network traffic and reducing your digital footprint.
I am not going to replicate the installation step here as they may update it at some point. Therefore, here is the link to the installation instructions:
Although, there are few points regarding my implementation that may help you with yours:
- Pi-hole as DHCP server – I had to use Pi-hole as the main DHCP server as the configuration of my ISP’s router as the main DHCP server caused some issues resolving local hostnames.
- Router as secondary DNS server – to support triple play services (i.e. IPTV and VoIP). Check the Support for Triple Play Services section below for more details.
- Disable DNSSEC on Pi-hole if using Unbound – If you are using Unbound as a recursive DNS server, the DNSSEC option on Pi-hole must be disabled (see Adding an extra layer of privacy and security section below for details).
As mentioned as one of the key features, the web interface is a great tool to visualise what is going on with your domain queries. It also allows you to manage Pi-Hole’s whitelist/blacklist and application configuration. More details can be found in the Pi-hole documentation.
Adding an extra layer of privacy and security
Apart from blocking ads, you can also use your PiHole solution to include your own recursive DNS server. The Pi-hole as All-Around DNS Solution page gives you a brief introduction to what a recursive DNS is, its benefits and drawbacks along with instructions to install Unbound DNS.
There is an article from Linux Magazine that gives some good information about Unbound DNS features along with some configurations.
In short, Unbound (as a recursive DNS) will resolve the domain names directly with the respective reponsibles for that domain and store the results in order to be reused by any other device in your network. This avoids (to some extent) that someone (i.e. your ISP) logs your browsing activity. Unbound also uses DNSSEC, avoiding your DNS to be tampered with or altered.
As mentioned in the beginning of this article, I had to disable the DNSSEC setting on Pi-hole DNS configuration as Unbound is already doing the DNSSEC validation.
I first had this setting enabled but started to see some issues resolving few good domains, resulting in malformed pages and invalid DNS responses. I googled this issue and the most reasonable explanation for this behaviour is regarding bugs when using DNSSEC and dnsmasq. Tore Anderson’s article about DNSSEC Validators presents a few problematic points with this combination and led me to believe that Pi-hole’s implementation of dnsmasq (FTLDNS) was the main problem. This is because the current FTLDNS version (v4.4) uses (AFIAK) dnsmasq version 2.80 in its implementation and, according to Tore Anderson’s article, the mentioned DNSSEC related bugs were fixed in dnsmasq version 2.81.
Pi-hole have just announced as an Easter gift that they have included dnsmasq 2.81 in their Pi-hole 5.0 beta testing program and it aims to fix many DNSSEC issues that have been reported during the past few months. I didn’t have time to test it and probably will wait for the final release as me and my wife use it while working from home. If you are in the same situation as I am, disable DNSSEC setting have been a good workaround.
Quick update (27/04/2020): I’ve been testing Pi-hole 5 beta for the past week and the DNSSEC problem is fixed with dnsmasq 2.81.
Support for Triple Play Services
If you have extra services with your broadband package (i.e. TV and Telephone), using PiHole as the DHCP solution may break some of the functionalities as some devices (such as the TV Box) will need the ISP’s DNS to resolve names for their respective services.
In my case, I had to configure my TV box to use ISP’s DNS instead of Pi-hole/Unbound. The solution was to label my TV box in the DHCP configuration and use it to redirect its name resolution queries to ISP’s DNS. The diagram below shows a high level view of how the name resolution routing is working on my network.
In order for this configuration to work, I created the file /etc/dnsmasq.d/03-tvbox.conf and added the following lines:
Note that the MAC Address (in bold) is the one from my TV box. It’s usually located at the bottom or back of your box.
If you have a display for Raspberry Pi, you may be interested in the Personal Access Display Device project (a.k.a. Pi-Hole Ad Detection Display). It will enable Raspberry Pi to present some useful statistics on the display.
I used a very rudimentary approach to check the performance increase from two main aspects that were bothering me: page load time and CPU consumption. Although it’s not very precise, this is a test that anyone can do without much IT expertise.
I got the CPU load figures from observing the respective Chrome process during and after the page load. You can use the Activity Monitor on MacOS or Task Manager on Windows.
To get the page load time I used a Google Chrome extension named “Web Performance API Timing“, but there are many others on Chrome Web Store that can do the job.
I used the following news page which was very popular in the UK over the past weekend:
The pictures below group some screenshots of the tools used during the tests (note that I measured the CPU utilisation while the page was loading and after it was completely loaded).
Summarising the figures above we have:
|Criteria||Without Pi-hole||With Pi-hole|
|Page Load Time||10207ms||795ms|
|% CPU (while loading page)||113.08||32.01|
|% CPU (page loading completed)||42.69||3.04|
In this specific scenario the results were quite significant. When switching to Pi-hole the same web page loaded more than 10x faster and consumed less than a third of my CPU during the loading. After loading the page we can also notice a decrease of more than 90% in CPU consumption when ads are not present.
With everything configured and tested, the last step was to close the case and hang it beside my router.
12 23 4