Pi-hole: 4 years later
In 2017 I installed a Pi-hole into my network and routed all my internet traffic through it. Today is now March 27, 2022 and I've been running it ever since.
My last post about this went into detail about the PiVPN integration I did to support VPN access via Wireguard. That has since been removed and added into my OPNsense firewall directly. I then additionally followed this wonderful tutorial to use my existing Pi-hole setup with OPNsense.
The long-term data solution I built is still going strong with all extracted data being removed from the Pi-hole to keep it lean. This is of course less of a concern now, because the HDD on the Raspberry Pi was upgraded from 6GB to 28GB usable space.
The Pi-hole software has also jumped with releases from 5.5 to 5.11, so we have a few versions to recap.
- 5.6 - Upgraded dnsmasq, show DNSSEC queries and bug fixes
- 5.7 - Correctly proxy iCloud Private Relay and upgrade fixes.
- 5.8 - Fix FTL issues with CNAME inspection and rate limiting.
- 5.9 - Upgrade dnsmasq and Gravity DB handling improvements.
- 5.10 - Cleanup UI appearance for menus and update sqlite.
- 5.11 - Enable history for SQLite, optimize web with animations.
We saw these release notes give a more automatic dump of changes from the variety of repositories that produce Pi-hole. This makes it slightly more difficult to find the key points of each release, but helped find each contributor and change that made up a release.
The dashboard has gotten a face-lift in a few areas and eagle-eyed users would notice my amount of clients has gone up by about 7 and the percent blocked is now roughly 8% instead of 3%. I think this is an extremely interesting that the amount of traffic I send now is 5% heavier in terms of blocked requests than last year.
So lets dig into the top 15 blocked and allowed requests to see what led to that. This time looking at 40,997,056 requests over the last 1,002 days of long-term data collection.
Top 15 Blocked
Top 15 Allowed
Right out of the gate you can see the snafu of
.local domain multicast spamming that plagued nearly 17 million requests since the release of Big Sur. I've since turned my local TLD to
pihole so each device gets named like such and works around that issue that was caused by using
This is easily more seen if I screenshot the last few requests through the system.
So you can see the devices using the new
.pihole TLD, as well as switching to DNS servers that use DNSSEC. I haven't perfected this process yet, but I'm just now starting the switch to slowly move to secured only DNS requests.
If you look at the blocked requests above, it looks roughly like I expect:
- Google Analytics
- Microsoft Telemetry
- Google Ads
- Nielsen Tracking
- Application Session/Error Tracking
Though, I do notice a new domain climbing extremely fast to the top 15. It has lodged 31,000 blocked calls and only started 3 months ago. That is roughly 10k blocked calls a month and is
us-tracking.nextdoor.com. Which matches exactly to when I installed the Nextdoor application.
I'm glad I have a Pi-hole, because I'm going to dig into what that endpoint is sending for a future blog. I am noticing my upstream data collection is about 2 weeks behind so might have to dig into a way to let that catch up.
Either way, another year running Pi-hole and no complaints. Pass on a donation to the Pi-hole team if you appreciate what they are doing.