DNS based ad-blocking is great, until it’s not. I’ve wrote a lot about Pi-Hole, pfBlockerNG, Ad-Guard, and other services. I’ve used DNS based ad-blockers for years, and I will continue to use them until ad hosts start running all of their ads off the same network as the content (ala. YouTube).
Despite how much I like DNS based ad-blockers I also recognize there are some problems with them, and this blog post is my documentation of one of those issues which I don’t see mentioned very frequently.
Normally the problem with DNS based ad-blockers is that people will load in too many lists or won’t check the lists they load in and will inadvertently block something they need. I’ve seen lists where people, in an effort to block Windows Telemetry, have wildcard blocked everything Microsoft and Windows. This however isn’t that situation.
A while ago I bought some Kindle Fires for my kids and at first the battery would last several days. However, after a short time the battery would only last for about five hours. The battery went from lasting several days in standby mode to only lasting five hours in standby. I actually sent the devices back to Amazon at a point because of the battery issue. Amazon said the problem couldn’t be replicated and sent it back to me. That’s when I started looking into other potential problems.
I opened my, at the time, Pi-Hole dashboard and noticed a massive uptick in two specific domains.
www.device-metrics-us.amazon.com
www.device-metrics-us2.amazon.com
I noticed there were tens of thousands of DNS requests to these domains coming from the IP addresses of these two Kindle Fires; every one of them blocked. I made a hypothesis that these domains being blocked was causing some issues with the Kindle Fire.
To test this idea, I changed the DNS server IP on the Kindle and to my amazement the battery life returned to multiple days. I unblocked those domains on my Pi-Hole, and everything has worked fine since.
As best as I can tell what was happening here is that the Kindle Fire would send some form of telemetry packet to www.device-metrics-us.amazon.com and if it failed to reach that domain it would then send a packet to www.device-metrics-us2.amazon.com. If both of those failed, then the Kindle Fire would dramatically ramp up the attempts to reach those domains. Now this bit I can prove. I can record how often the Kindle reaches out to those domains when not blocked and compare that to when it is blocked. When unblocked the Kindle only reaches out to the first domain about once an hour, but when blocked it will attempt to reach out thousands of times a minute.
This next bit is educated speculation, or a hypothesis. I believed that when the Kindle cannot reach the domains and begins to ramp up the sending of data that if cannot go into standby mode and therefore never properly goes to sleep. This lack of sleep means results in rapid battery drain on the device and a short battery life.
So, there we go. I wanted to document this to show two things. First you need to understand what domains you’re blocking. And second, because I hadn’t seen really anything talking about this problem with Kindle Fires before I noticed it and reported it about a year ago.
Hope this helps someone else.
