Ramblings of a Tampa engineer
Screenshot of Pi-hole 5.18

In 2017 I installed a Pi-hole into my network and routed all my DNS traffic through it. Today is now February 26, 2023 and I've been running it ever since.

This last year was the hardest of running Pi-hole in the history of this little project. It all started when one regular upgrade went south and it refused to complete. It turned out that running Raspberry Pi OS (Stretch) was no longer supported.

1041 upgraded, 735 newly installed, 11 to remove and 0 not upgraded.
Need to get 1,322 MB of archives.
After this operation, 2,179 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Stretch to Buster

I took a risky jump and did a in-place upgrade from Stretch to Buster to Bullseye. So now that I was up to date on my operating system I could resume my upgrades on the Pi-hole. Once done I completed the upgrades from Pi-hole 5.11 to 5.18:

A cool part of this upgrade was the introduction of PADD which was the upgraded version of the Chronometer2.


This is a pretty nifty feature compared to the previous - a great quick command to get quick insight on the status of the Pi.

During the last year I also gained a Prometheus and Grafana server in my local network. So I dug into how to push Pi-hole data into that project in order to add Pi-hole data into my dashboards. I found a simple exporter and with that my Prometheus server was gathering the data.

Prometheus target for Pi-hole

So then I found a Grafana dashboard and did a bit of configuring and had a new dashboard to contend with. The purpose here isn't really to replace the existing Pi-hole dashboard, but to use the available data to slowly build my own personal dashboard of all home data available.

Grafana dashboard

So now all my new bells and whistles were up and running - it was time to do some data exports and see how the blocked/allowed queries were handling.

So I jumped onto my internal "pi-stats" project and executed php artisan stats:dump and waited. With over 40 million records its showing how inefficient some of these queries are I produced.

The script took ~90 minutes, but then dumped out the following stats:

Total Queries: 41,676,108
First Query: 2019-06-17 00:55:35
Last Query: 2023-01-28 21:19:47
Time in days: 1321
Time taken: 90 minute(s).

Top 15 Allowed

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 3,643,663
806c4c48-1715-4220-054f-909f83563938.local 1,342,386
b.canaryis.com 1,111,227
pistats.ibotpeaches.com 588,559
api-global.netflix.com 376,154
clients4.google.com 361,808
ssl.gstatic.com 328,905
cdn-0.nflximg.com 322,484
nrdp.prod.ftl.netflix.com 319,364
play.google.com 312,519
www.google.com 280,645
ichnaea.netflix.com 279,543

Top 15 Blocked

Domain Count
806c4c48-1715-4220-054f-909f83563938.local 803,900
e7bf16b0-65ae-2f4e-0a6a-bcbe7b543c73.local 638,460
1d95ffae-4388-9fbc-1646-b2b637cecb64.local 432,008
ssl.google-analytics.com 379,597
68c40e5d-4310-def5-a1c3-20640e1cd583.local 247,892
app-measurement.com 246,464
watson.telemetry.microsoft.com 217,743
googleads.g.doubleclick.net 87,587
settings-win.data.microsoft.com 71,150
www.googleadservices.com 62,735
mobile.pipe.aria.microsoft.com 47,406
sb.scorecardresearch.com 47,058
sessions.bugsnag.com 44,110
reports.crashlytics.com 39,801
secure-dcr.imrworldwide.com 36,591

So lets take a look at the top few on both sides. The random UUID domains are still here and might take years to be bounced out of the top 15. If you remember these were from the multicast behavior added in Big Sur, which caused tons of requests to be made to any .local domain. Why they wouldn't stop if the other device(s) didn't respond properly after the first 100,000 requests - I don't know.

I renamed the devices to end in .pihole and that has halted Mac from reaching out to them nonstop. However, even 2 years since that fix - those requests are still leading both the blocked and unblocked. My network does look extremely different than prior with the introduction of a switch and a firewall. I blogged about this new setup prior, which may explain some of the new differences in my top 15 blocked and allowed domains.

The top blocked domains still fit into categories of:

  • analytics
  • bug tracking / analytics
  • ads
  • dumb Mac multicast spamming

The top allowed domains are:

  • Canary security system
  • Pi Stats (this internal stat project)
  • Netflix
  • Google Play
  • dumb Mac multicast spamming

So I think in order to have a sane dataset - I should purge all these multicast domains from the history. It might save me 15~ million records and make this research a bit more interesting.

Pi-hole continues to evolve and be a great addition to my local network. I'll pass another donation and see them again in another year with another yearly blog post.

You’ve successfully subscribed to Connor Tumbleson
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Success! Your email is updated.
Your link has expired
Success! Check your email for magic link to sign-in.