When implementing Pi-hole on my home network, I thought of it as a set-it-and-forget-it thing, as most of the community discussions suggested. I installed a Pi-hole home Debian serveradded several authoritative blocklists and set it as the default DNS for me dual WAN gateway. And for a while, it really did seem like it was over. The ads disappeared, the obvious trackers were filtered, and the dashboard showed me thousands of blocked requests.
Out of curiosity, I made a habit of checking the dashboard randomly. When I filtered the query log by the local IP address of each device, especially my smart devices, this habit became a mere curiosity. I found my IoT devices talking throughout the day, even when sitting idle. I started researching these requests and the research turned out to be more interesting than the fix itself.
My block list was lying to me
Survey magazine told a different story
When I set up my lab, DNS was not part of my initial stack. Pi-hole started as an ad blocker and gradually became mine default DNS for my entire home network. Although I only used it as an ad blocker, I checked the query log every now and then, not because I was solving anything, but as a random habit. When building Pi-hole, I used the most recommended blocklists: the OISD biglist and Steven Black’s single host blocklists. I assumed that if one of my devices used Pi-hole, community blocklists would already be sufficient to capture telemetry and monitor traffic.
Everything was fine and working as expected until I tried to filter requests per device by local IP addresses. I have a number of IoT devices such as an Amazon Echo Dot, two Amazon Fire TV Sticks, multiple smart switches like the Tapo P110, smart bulbs and Android TV boxes. Filtering by individual IP addresses told me a different story. I specifically chose three of my most used IoT devices—the Echo Dot, Fire TV Stick, and Tapo P110—and started digging. Together, they were responsible for thousands of requests in a single day, and I noticed that TP-Link’s Tapo cloud domains had a lot of Amazon domains showing up multiple times. The surprising part was that most of the requests were easily passed by Pi-hole.
It was linking to domains like Tapo use1-cvm-api, aps1-device-cloudgatewayand security.iot.i.tplinknbu.com throughout the day. Echo Dot’s diagnostic AWS domains were wildly duplicated, e.g web.diagnostic.networking.aws.dev and its regional variants (ap-south-2, ap-east-2) are fired almost every minute. But in the case of FireTV Stick, there were several requests every minute, but fortunately, some of them were already filtered by Pi-hole, e.g. mobile-collector.newrelic.com and api.statsig.com. These were common third-party analytics SDKs, so the community blocklists already covered them. But there were still a few things the blocklists didn’t touch, like Amazon’s own infrastructure domains. unagi-eu.amazon.com and hash a2z.com device identifier domains.
After all, it was difficult for me to understand which of the remaining domains could disappear without taking the device with it. Because one bad guess and I could render my Echo Dot useless.
Not every domain deserves a free link
One bad guess and Alexa is silent
When I looked at the logs, my first instinct was to block everything. But these were smart devices that required the internet to work properly, and blocking everything meant blocking them from the bare minimum needed to function. If I blocked the wrong endpoint, it could break the voice assistant or stop cloud control, software updates, or account validity.
So I started to figure out which domain does what and put them into two buckets. Pure telemetry that is safe to kill as AWS diagnostic endpoints (web.diagnostic.networking.aws.dev), device identifier services (*.us-east-1.prod.service.minerva.devices.a2z.com) and background report (unagi-eu.amazon.com). And the domains needed for the device to actually work, such as the Alexa API (api.amazonalexa.com), TP-Link cloud gateway (aps1-device-cloudgateway.iot.i.tplinknbu.com) and anything that explicitly handles commands, authentication, or device communication (use1-cvm-api.i.tplinknbu.com).
A few more signals helped distinguish them, such as how often they appeared and whether requests occurred even when the device was idle. And a few domains just told the story of what they did: security.iot.i.tplinknbu.comfor example, I did not feel safe to hinder a guess; It seemed like something that Tapo really depended on. A few hours of internet research, plus a bit of gut instinct, and I was ready to remove these from my network.
The correction was smaller than the investigation
I didn’t need a better blocklist. I needed six lines
After completing the investigation, there was a short list of domains that were safe to block and a list of other domains required for the devices to work. But there were still a few that needed to be checked out because the name suggested a different story. I went through many community discussions and official documents before making a final decision.
Security.iot.i.tplinknbu.com seemed important at first and later I found it to be important. Suggested reports it was involved in Tapo’s cloud connection, and blocking it could prevent smart switches from working normally. The other was msh.amazon.co.uk. At first it seemed important, but it turned out to be less critical than expected. Blocking it won’t kill my Fire TV Stick, but it might slow down app installs, so I decided to give it a free pass.
With the obscure domains out of the way and a good short list of domains to block, the application was a matter of minutes in the Pi-hole dashboard. I added six entries to the pi-hole deny list. Four of them were fully qualified domains and two were wildcards.
api.statsig.com
mobile-collector.newrelic.com
firetvcaptiveportal.com
unagi-eu.amazon.com
(\.|^)prod\.service\.minerva\.devices\.a2z\.com$
(\.|^)diagnostic\.networking\.aws\.dev$I waited a few hours to get everything sorted out. The results were clean. Most of the unnecessary requests for Echo Dot, Fire TV Stick and Tapo P110 were then blocked. Telemetry domains now consistently displayed “Deny” instead of “Allow”. Most importantly, all the devices worked as expected. Ultimately, the fix was just six lines added to the Pi-hole deprecated list. The hard part wasn’t adding them to the blocklist, but spending hours figuring out which ones belonged there.
Set-and-forget was a real mistake
Pi-hole was not a failure. It was already filtering thousands of third-party trackers. Blind spots were vendor-specific telemetry that general community blocklists weren’t built to catch. After all the research, my old set-it-and-forget-it instinct has changed to occasionally reading survey logs. Spending just a few minutes on logs can reveal patterns that community blocklists often miss. In my case, six lines on three devices was enough. The rest of my network probably hides a few of its own.
- OS
-
Linux
- Price model
-
Free
Pi-hole is a network-wide ad blocker that acts as a DNS hole and prevents unwanted ads, trackers, and malicious domains from being loaded onto any device connected to your network. Runs on lightweight hardware like Raspberry Pi or virtual machine. By intercepting DNS requests, Pi-hole blocks ads before they reach your browser or apps, improving speed and privacy. It also provides an easy-to-use web interface for monitoring and managing network traffic.
