So my pi-hole died yesterday. After a brief look, it turned out that the filesystem was full due to heaps and heaps (about 1.5 Mio) of queries like the following over the course of 2-3 hours:
Feb 7 20:31:49 dnsmasq[786]: query[A] 2632fd5c-fcca-46ae-9bb1-2bdf403e0fda.probe.performance.dropbox.com from 192.168.0.105
Feb 7 20:31:49 dnsmasq[786]: forwarded 2632fd5c-fcca-46ae-9bb1-2bdf403e0fda.probe.performance.dropbox.com to 208.67.220.220
this completely blew up the /var/log/pihole.log and eventually brought the filesystem to 100% usage.
Since 192.168.0.105 is the IP of my Wifi router, I cannot determine which device actually caused the effect. For now I blocked the above dropbox address as soon as the queries started again the next day and things are fine so far.
Some questions, though:
has anyone seen this flood pattern before?
is there some kind of flood-protection means to recognize and prevent something like that?
and probably out-of-scope here: I tried to find out with ntopng which wifi device was causing the effect but failed (no real experience with ntopng) - what's the recommended approach to track down the culprit in such a situation?
The question is: Wich device will probing performance against dropbox? As far as I experienced there are some devices like network (audio-)players (with buggy firmwares) can cause effects like this. These devices won't accept answers the don't expect like pihole blocking or unanvailable services and then they're polling a hundret times a minute. Do you have a multimedia device that can play files from clouds and network storages?
Here is something that might help you.
I bookmarked this post a while ago, knowing that, sooner or later it might be useful.
Basically, it comes down to preventing the DNS request to get to pihole, using iptables, thus no entries in the query log and other pihole views. I've never tested the solution, all credit to the author of the reddit post, but it looks like a solid solution.