Note: I ran some searches on this problem and didn't notice anyone suggesting this solution, so I figured I would share it. If it's been done before and I just missed it, then I apologize.
There seems to be some apps/devices that are a bit spammy if they get blocked. Notably, roku smart TVs and related devices are a big offender, but I've also noticed that some app on my wife's smartphone apparently likes to get noisy when it doesn't get its way.
The two URLs I've experienced as major offenders are:
scribe.logs.roku.com (roku devices)
api2.branch.io (smartphone apps)
Since there's probably more out there than just the two as offenders, I thought I'd share my work-around to help reduce how chatty they are, just in case it helped someone else. Maybe it's not that big of a deal to you, and you just whitelist them. But I'm stubborn, and I refuse to let them win, so I've come up with an over-engineered 'solution'.
The concept is to make the device or app think it has a good domain name, and then waste time trying to connect to something that's not real. Normally, the pihole software replies with a 0.0.0.0 response telling the device that it couldn't be found, and so the device requests again and again - as though it's throwing a tantrum until it gets its way.
What to do
Practically speaking, here's what you do:
- Set up a custom DNS entry under Local DNS --> DNS Records in the web interface for scribe.logs.roku.com (or whatever offending URL you have)
- Point it at an IP address that you know will never resolve to anything real. (I chose 192.168.192.168)
- Then whitelist that domain so that it resolves to the new IP instead of getting a blocked message.
I also like to set a block in my router for that domain as well, so I know it's not going to leave my network, just in case the device tries to bypass my pihole entirely, but that's a separate issue.
I recently discovered a better way to do the above, using Pihole's regex functions. Here's two blacklist examples to get you started:
Note that you can use the ;reply= notation to reply with any other kind of blocking message as well, making this method far more versatile than my previous one.
(ex: "scribe.logs.roku.com;reply=nxdomain" would reply with the nxdomain blocking mode for queries matching "scribe.logs.roku.com".)
For information on the ";reply=" regex options, look here: docs.pi-hole.net/regex/pi-hole/
For information on blocking modes, look here: docs.pi-hole.net/ftldns/blockingmode/
After running this for a couple of weeks, I've noticed somewhere between 1/4th and 1/2 the number of requests to these domains on my network, (depending on time of day, how much the devices were used, and other factors) and the massive spikes causing my roku to get a DNS timeout have stopped.
The only thing I can think of that would improve the functionality of this is if you could direct it at a web server that would always respond with an HTTP 503 message. Ideally one with a REALLY long delay specified in the Retry-After header. This would hopefully make the device think it successfully connected, but that it just had to wait a bit. Hours if we're lucky. But even just a few minutes of wait time would put a huge dent in this spam.
The obvious roadblock to this is having a trusted certificate for a domain you don't own so that the device will easily connect over SSL to get the message. There may be a way to trick a device or app into using plain HTTP instead, however, so I wouldn't rule this out entirely.
It would also be cosmetically nice if there was support for blocking certain URLs in this way baked into pihole. As it stands, these URLs now show as ALLOWED when I know they're being blocked. But that's a minor cost for saving my network from an internal DDoS caused by these spammy devices. I'll put in a proper feature request for this if this kind of rude behavior becomes more common in modern apps & devices.
Maybe some of the geniuses in here can improve on this technique further? What do you guys think?