Just noticed that my Brume2 (v1.8.2 beta) with activated DNSCrypt blacklists “tracker.*” which in turn also blocks the legitimate tracker.debian.org, a service for tracking Debian packages. I resolved that by removing that entry from /etc/dnscrypt-proxy2/blocked-names.txt.
Edit: Noticed the wording can be misleading - tracker.debian.org is not a tracker in the sense of website tracking (with cookies or similiar). It’s just a website informing about Debian packages and not reachable when DNSCrypt is activated.
I ask to either whitelist tracker.debian.org ba default or to rethink the whole default config for that service.
You can add a specific rule to your dnscrypt-proxy config to forward this to another, non-filtering dns server. Look for forwarding_rules in documentation for dnscrypt-proxy.
Yes, I can also do that in the GUI. But my request is about sane default settings, not workarounds.
There is also something else going on here: I had setup DNSCrypt-Proxies over HTTP if I remember correctly (set that up a long time ago). After playing around with the settings I could not select DNS over HTTP anymore. Is that gone generally or just in the latest beta or something on my system?
They have to balance the needs of the few with the benefits to the many. There is a way to override this behavior, as you know. It will not be perfect for everyone.
I agree with @D.D here. I noticed today that the defaults with this package are undesirable due to issues with my Brume 3 and was actually going to create a post about it myself. So this saves me a job. I expect this is common across all devices due to the nature of the issue.
Electing to enable DNSoHTTPS on my device should not filter any DNS records by default, period. If I chose to filter records this should be my choice. Having stealth filtering blocking DNS records hidden undocumented in a config file that starts blocking DNS just because you enable a feature that is nothing to do with DNS filtering is not sensible default behaviour.
This may be the default config for the package used to provide the encrypted dns functions, but as it’s installed by GL in the firmware out of the box these default filters should, in my opinion, absolutely be removed in future firmware releases. Those that want to use them should enable them, not the other way around.
Recently I was guided to discover that *.local is also in the blocklist by default, which compromised mDNS functionality for all the Raspberry Pi nodes on my network. Commenting out that line fixed things for me, but not after losing a lot of time trying to troubleshoot and then needing to get support to help me figure it out. Support was very helpful and quick, but I agree that the default blocklist should be less restrictive to save others from such trouble.
Thank you everyone for the discussion on this matter.
We have already asked our development team to evaluate possible changes to this list in future versions — it may potentially be removed in order to avoid filtering behavior being applied by default without users being clearly informed.
Of course, if there are still users who would like to enable it, we may also provide some tutorials for advanced users as a reference in the future — or even explore whether it can eventually be integrated into the GL UI.