Definitely possible. If adblocking via DNS becomes super common, perhaps this will happen. I think more sites will serve up ads from their own domain, personally.
Also in case you’re curious about power consumption of the 3b+ versus older Pis:
I’d expect a pi-hole device to be “near idling” most of the time, so 230mA is the realistic floor for recent Pi models that have ethernet.
Here we see 350mA idle, which is ~2w. Maximum realistic is just over 5w at full synthetic CPU load.
Do give a try to https://technitium.com/dns/ on your Raspberry Pi which can block Ads based on block lists and has some advance features like built-in DNS-over-HTTPS, DNS-over-TLS and ability to use SOCKS5 proxy + Tor network to allow using Cloudflare hidden DNS resolver.
I hate what’s happened to the web. Many articles are now unreadable and ironically try every trick in the book to distract you from the content you came to read.
But, if you’re going to use an ad blocker then you really need to meet them halfway and address the root cause - you need to pay for the content that you value the most. The reason this has gone so over the top is that so many outlets are struggling to survive.
Apple News+ is an interesting approach to this problem and to me it’s quite refreshing to be able to just read content from a diverse set of sources without having to weed through the distractions.
My Asus router lets me set custom DNS servers for the DHCP clients on the network, and I’ve been using OpenDNS without any blocking (using uBlock Origin on browsers). I’ve got a Ubuntu server running on the network, I might install pi-hole on there and point my DNS over there for a bit, and see how it works.
One concern I might have, though, is that there are some folks in this household that play app-supported games on their phones/tablets, and I don’t know how those apps will behave under ad blocking.
Currently you can setup your mobile device to VPN into your PiHole to use it as the DNS server, even on the go. The new thing that should make this better is WireGuard, which is what the 184.108.40.206 mobile app is using. (CloudFlare claims their implimentation uses LESS power that a traditional VPN. If that is true, and they have released their implementation as open source, even on devices whose Linux Kernel doesn’t support it, this will probably bea win.)
I haven’t switched completely to Brave, but there are so many tools to sync bookmarks and all the Chrome extensions work in Brave, so I’m not sure what’s holding me back. For testing, I like having a separate browser sometimes which I use Brave.
Worse is that some adverts come complete with exploits that attempt to hack your systems. I’ll consider switching off my adblocker only once advertisers stop pop-over adverts, adverts with sound, and adverts with exploits.
Interesting article and responses but, at the risk of being off-topic, I wondered what the situation is with browsers other than Chrome (particularly Firefox). Are these also at risk from Google’s impending changes?
While I’m sure my default setup of Firefox with ABP/Ghostery and couple of other addins to deal with Flash Cookies and YouTube ads is technically inferior from a performance perspective, it keeps my screen adequately clear of junk. I’ve always been suspicious of Chrome (I’m old enough to remember the Google Add-on for IE which still relayed everything to HQ even when supposedly disabled) hence it only gets used for specific (application) purposes.
Any guidance much appreciated.
I think if the 3B+ actually had gigabit ethernet, it would show up in the iperf column. Compare it to the Macbook Air:
It looks like the new Raspberry Pi 4 has actual gigabit ethernet, so maybe you should update your blog post to recommend that?
Thanks for the blog post. I’d read Troy Hunt’s article about Pi-Hole a while ago, and initially I set it up running in a docker container which was a bit flaky. I bought a Pi 3B+ and set it up last night. Was my first Raspberry Pi experience and overall I am impressed with the kit! I might buy some more of them to play with.
It does have gigabit ethernet, but the interface is piped through a limited internal bus. It is still more than 2× faster than the 3B. As you noted, they properly fixed this bus bandwidth limitation with the 4.
Two important notes regarding the article:
- uBlock and uBlock Origin are not the same thing! The latter is the genuine article (and of pretty much undisputably good-faith behaviour), the former is a rather sketchy company. uBlock Origin, to my knowledge, certainly does not ‘contribute to the problem’, and does not run any Acceptable Ads-like programs.
- Pi-Hole is limited to DNS-based blocking. While this will block a lot of stuff, it won’t block all of it; and ultimately, it is in many ways more limited than Chrome’s new content blocking API. It’s probably not a good alternative if you’re looking for a better ad-blocking experience than that of Chrome. That having been said, it does have the benefit of blocking ads for all devices/applications on a network, including those without extension support.
cloudflareddaemon compiled for ARM (Raspberry Pi)
Configure it as a service that runs on startup under a user named
systemdto start the service (or reboot, I guess?)
Ultimately this still goes to Cloudflare’s
220.127.116.11 DNS, except routed over HTTPS:
# Commandline args for cloudflared CLOUDFLARED_OPTS=--port 5053 --upstream https://18.104.22.168/dns-query --upstream https://22.214.171.124/dns-query
Why? Basically, with traditional HTTPS people don’t know what you are browsing (because it’s encrypted) but they can definitely tell what website (domain name) you are looking at.
Even if you are visiting a site using HTTPS, your DNS query is sent over an unencrypted connection. That means that even if you are browsing https://cloudflare.com, anyone listening to packets on the network knows you are attempting to visit cloudflare.com.
The second problem with unencrypted DNS is that it is easy for a Man-In-The-Middle to change DNS answers to route unsuspecting visitors to their phishing, malware or surveillance site. DNSSEC solves this problem as well by providing a mechanism to check the validity of a DNS answer, but only a single-digit percentage of domains use DNSSEC.
With DNS over HTTPS, a man in the middle can’t see the content, nor can they tell what website you are on. Also prevents tampering with DNS as as side benefit.
I do this too, with a massive /etc/hosts file from Dan Pollack:
(I have a cron job to keep my local copy in sync with that version.)
It seems like this works just as well as Pi-hole. The advantage of Pi-hole is that it works for every device on your home wifi (without having to fuss with each device). The advantage of swapping in a curated /etc/hosts is that it works for your laptop regardless of what wifi you connect to (and without having to fuss with your router).
Why not just run a copy of pi-hole locally on your laptop, instead? Then you could copy the config over seamlessly. Considering pi-hole runs fine on (literally!) a Raspberry Pi Zero, which is extremely anemic, it uses almost no resources on a modern machine.
Ah, because I hadn’t thought of that. But does anyone actually know the pros and cons of running Pi-hole on one’s laptop vs swapping in a curated hosts file to /etc/hosts? I do the latter by cronning a command (nightly) like this:
/usr/bin/curl https://someonewhocares.org/hosts/hosts > /etc/hosts
(Actually my script does a couple other things to prepend custom stuff I needed in my /etc/hosts but I don’t expect that’s common.)
I know the /etc/hosts trick works for Mac and Linux but I don’t know about Windows. Maybe Pi-hole on one’s laptop is more portable/universal? But setup aside, is Pi-hole faster/better in any way?
On a forum that I run, users are always complaining about the light gray type - both on websites and in emails. And if the user is an older person, it’s even worse for their eyes.
For those privacy minded, we can do one better by not putting all our eggs in one basket. I have replaced cloudflared with unbound configured with many DNS over TLS forwarders so DNS requests are distributed among different servers.
I’ve added both IPv4 and IPv6 addresses in the above configuration example. Unbound will figure out which protocol is available and which is faster on its own. You can get better reliability from your DNS server by configuring more routes and more options to cover for outages or routing disruptions.
I also wrote about randomizing DNS forwarding servers with Knot Resolver a few weeks back. This ensures you’re not sending all your DNS traffic to one provider; making it more difficult for any one provider to build a complete profile on your online activities and behavior. Unbound will do this by default with no additional configuration assuming each of your configured DNS forwarders respond within 400 milliseconds. Note that you’re not limited to just four DNS forwarders as you are with Knot Resolver. You can configure as many DNS forwarders as you want with Unbound and it will spread your forwarding requests out among each of them automatically.
Adding a VPN like OpenVPN or wireguard so it uses pihole as its DNS will allow devices on the go to take advantage of this setup as well.
This is excellent, thanks for sharing it. After I posted about using DNS-over-HTTPS on twitter, people correctly pointed out that it is kinda obvious what websites you are visiting based on their raw IP addresses, so hiding your DNS queries isn’t that useful. Round robin to lots of DNS providers certainly makes more sense.