Pi-hole: 8 years later

In 2017 I installed a Pi-hole into my network and routed all my DNS traffic through it. Today is August 30, 2026 and I've been running it ever since. While I've lost the consistency of blogging exactly every year, this grows the collection of pi-hole posts on this blog.

We ended the last blog post on the release of version 6 of Pi-hole, which was followed by lots of patches still living under the v6 tag. My versions now reported at the footer are: Core (v6.4.3), FTL (v6.7) and Web (v6.6). Things generally have their own tags now between the FTL software, the Core and the Web. So it became a bit more difficult to summarize a changelog of them all. Roughly summarizing each release into a few words to catch us up over the last year.

• v6.0.5 (March 3, 2025) - Fixes for high RAM/CPU usage & slowness.
• v6.1 (March 30, 2025) - Hundreds of bug fixes.
• v6.2 (May 30, 2025) - Upgrades to tools, bug fixes, cleanup.
• v6.3 (October 25, 2025) - TLS & CSP improvements, security fixes.
• v6.4 (November 27, 2025) - Optimization & API improvements.
• v6.5 (February 17, 2026) - FTL enhancements for speed.
• v6.6 (April 3, 2026) - Lots of AI security fixes & Gravity fixes.
• v6.7 (July 6, 2026) - Security fixes, new DHCP lease editor and more.

If we summarized all those releases - things have stabilized as a product. There was no more flashy changes or rewrites. Just hardened, bug fixed products polished on optimizations. For something I entrust with all my DNS queries I'm happy for a stable product that I can trust isn't siphoning my data to sell.

Like I mentioned in the past the public feedback around Pi-hole has kinda shifted from my perspective. I can understand the reasons, because you have Pi-hole which has built a large chunk of its functionality on top of dnsmasq in low level C, then wanted to remove dependencies on PHP & lighttpd so introduced more C with civetweb. The talk around town was memory safe languages, security and more and Pi-hole got caught with a lot of security issues in languages not a lot of people felt comfortable in helping with.

This wasn't a bad thing because in the rise of AI - every project was finding things to fix. It just gave a chance for other services like Adguard, Blocky and Technitium to boost their marketing in the areas that Pi-hole suffered. Those alternatives rocked languages like .NET and Go which was a bit more attractive than a custom C codebase heavily maintained by one guy.

Though I'm not here to switch solutions or attack an open source project I've been donating to for years. I'm happy for what it does and will continue to use it. We wouldn't have gotten Gradle without Maven/Ant and we wouldn't have gotten Vite without Webpack/Gulp. Pi-hole started something allowing all these other projects to gain inspiration and thus exist.

Since the v6 release the tool PADD (Pi-hole Ad Detection Display) has been fixed, but I don't really use it anymore to have any actionable feedback.

A cool amount of stats which shows that roughly 10% of my traffic is blocked. With roughly 1.5 million domains on my blocklist though that seems less than I would expect. PADD hints at some stats, but they were never enough to scratch my itch. That is why I built Pi-Stats for long-term storage for my Pi-hole.

I signed into the Raspberry Pi that hosts it and sure enough it's still working just collecting data into a MySQL database. I jumped into a console session and executed php artisan stats:dump and waited a long time (14 hours).

+--------------------------------------------+-----------+
| Domain                                     | Count     |
+--------------------------------------------+-----------+
| e7bf16b0-65ae-2f4e-0a6a-bcbe7b543c73.local | 5,631,937 |
| 68c40e5d-4310-def5-a1c3-20640e1cd583.local | 5,305,150 |
| 1d95ffae-4388-9fbc-1646-b2b637cecb64.local | 4,898,205 |
| localhost                                  | 4,461,025 |
| 1.1.1.1.in-addr.arpa                       | 2,061,743 |
| ping2.ui.com                               | 1,528,752 |
| ping.ui.com                                | 1,509,934 |
| www.gstatic.com                            | 1,486,086 |
| 806c4c48-1715-4220-054f-909f83563938.local | 1,342,386 |
| 8.8.8.8.in-addr.arpa                       | 1,203,524 |
| api-0.core.keybaseapi.com                  | 1,184,543 |
| b.canaryis.com                             | 1,127,482 |
| 168.192.in-addr.arpa                       | 1,061,695 |
| pistats.ibotpeaches.com                    | 1,050,674 |
| ui.com                                     | 909,261   |
+--------------------------------------------+-----------+

Everything here looks to be expected. The weird multicast domains from an older Mac, the Hue lights and Keybase. Its crazy Keybase is still up there - its from that flaw they had a few years ago when an SSL cert expired. The application just never stopped pinging domains in an endless loop, thus racking up a million requests until I noticed and upgraded it.

+--------------------------------------------+---------+
| Domain                                     | Count   |
+--------------------------------------------+---------+
| 806c4c48-1715-4220-054f-909f83563938.local | 803,900 |
| e7bf16b0-65ae-2f4e-0a6a-bcbe7b543c73.local | 638,460 |
| ssl.google-analytics.com                   | 509,615 |
| app-measurement.com                        | 455,434 |
| 1d95ffae-4388-9fbc-1646-b2b637cecb64.local | 432,008 |
| logs.netflix.com                           | 317,313 |
| androidtvchannels-pa.googleapis.com        | 300,860 |
| mask.icloud.com                            | 275,727 |
| 68c40e5d-4310-def5-a1c3-20640e1cd583.local | 247,892 |
| watson.telemetry.microsoft.com             | 217,743 |
| googleads.g.doubleclick.net                | 200,577 |
| trace.svc.ui.com                           | 165,314 |
| g.live.com                                 | 149,472 |
| beacons.gcp.gvt2.com                       | 138,396 |
| beacons.gvt2.com                           | 133,649 |
+--------------------------------------------+---------+

A new domain to the list was iCloud, but in the last year I purchased my very first Macbook and Alyson moved in with an iPhone as her personal phone. I'm guessing either of those led to an influx of iCloud domains being blocked. The rest is normal ad blocking with Netflix, Google, Hue and Microsoft stuff. Happy to see I'm not contributing more and more of my usage/information on top of already paying for most products up there.

A new feature to Pi-Stats was to dump out the domains per year since looking purely at the all time was reluctant to change. That single multicast issue caused million of domain requests which will take a few years to bounce out of there. I'd rather not do a partial year so I'll do an all-time and 2025 breakdown this time around.

Year: 2025
Top 5 Allowed Domains
+------------------------------------+---------+
| Domain                             | Count   |
+------------------------------------+---------+
| ui.com                             | 281,529 |
| 1.1.1.1.in-addr.arpa               | 240,923 |
| ping.ui.com                        | 177,842 |
| ping2.ui.com                       | 155,417 |
| agent-services.prod.cavelodata.com | 143,044 |
+------------------------------------+---------+

Top 5 Blocked Domains
+-------------------------------------+--------+
| Domain                              | Count  |
+-------------------------------------+--------+
| mask.icloud.com                     | 80,981 |
| mask-h2.icloud.com                  | 80,262 |
| androidtvchannels-pa.googleapis.com | 76,159 |
| logs.netflix.com                    | 70,922 |
| api.segment.io                      | 38,790 |
+-------------------------------------+--------+

I didn't recognize "cavelodata.com", but it appears to be a domain used for protection of work machines. I know the software we use at my own work, so this is probably something on Alyson's work computer. iCloud, Netflix and Android TV analytics lead the charge on the 2025 view and it makes sense. We have an NVIDIA Shield and that's where we watch all of our TV, with a bit of Netflix.

Running these reports on a little Raspberry Pi with 100's of millions of stored records is no easy task. I'll have to brainstorm an even better solution of storage for the future. I probably don't need to recalculate older years once done, so I'll expand the DB for a yearly breakdown. I might rethink the setup entirely perhaps with a domain table having a count alongside first/last seen date. If I can move the work to insert time instead of query time - it'll be much easier to run reports on the data.

For now with Wireguard routing my laptop and phone back to my home network where my Pi-hole sits. I gain the benefit of no ads no matter where I'm at. I once accidentally forgot to active my VPN and I forgot how terrible the web is without blocking ads and that's only what I can see! Who knows how much metadata is being harvested to fingerprint your device on advertising requests to 3rd party systems. I'm happy I have Pi-hole keeping me protected at home or on the go.

Pi-hole has probably stabilized in terms of features, but I'd still recommend it for a local personal network. I'll try and remember to do a year 9 update a bit more on schedule next year.