[Fnoord]

Yeah, that's a given because they're not constructed manually ie. no manual verification.

Give them some time to react. My wife complained to me she could not visit a website (I run Pi-Hole on our network, and our mobile devices get routed to it even on external networks). I looked through the logs, figured the offending rule, contacted the maintainer, and they fixed it within a few hours.

The issue has been up for one hour thus far.

[xoa]

Yeah, same here, I run OPNsense and make use of Unbound's blacklist feature to similar (and surprisingly potent!) effect, along with Suricata and Sensei. I have had to manually whitelist some stuff though.

False-positives, things that are good defaults but advanced users should be able to bypass, or just plain unfortunately necessary workarounds are certainly all issues though. I think user available fallbacks can be useful sometimes for that reason. Like at a site using 802.1x auth, set it up so users can append "-noblock" to their login and then it'll change them into a different VLAN which can just point at a different DNS (or alternately Unbound supports views for split-brain DNS).

[Fnoord]

I don't want to educate my wife about how to circumvent the blockade with an all or nothing decision. I mean, its possible, and I taught her to update Google Play over 4G because else it does not work (on Nvidia Shield and Google Pixel 3a it does not; on all my other devices it works, not sure why). The reason I don't want to teach her that, is that the measure helps her (and our) privacy and security. By temporarily giving that up, we open up the whole attack surface for that time, which is kinda OK if you remember to switch back immediately but people tend to forget... The correct way to solve the problem is by fixing the blacklist and/or whitelist, (temporary) collateral damage be damned.

I use Pi-Hole on EdgeOS with a second server with Docker as backup. I also have NextDNS as fallback. I'll probably switch to OPNsense at some point though.