Not only this one. If I set NextDNS for encrypted DNS provider in Mozilla settings it is not blocked either.
For example if I set encrypted DNS to be used on any Android smart phone it cannot access the internet via my WiFi network and that is OK.
I'm sorry for being stupid, but what exactly is not blocked?
It should block the settings of your encrypted DNS in browsers, OS, etc. That is, either go to the Internet through the router settings or don’t go at all.
1 Like
Who told you that?
The settings of the program in question, for which there is even a menu item with explanations.
You're misinterpreting it.
I block use-application-dns.net, mask.icloud.com, mask-h2.icloud.com and forward port 53 via adblock addon and it works as expected. The difference is that I don't expect Google Chrome to respect it...
2 Likes
My English is bad, of course, but not so bad that when following links to a page with detailed explanations of what and how it should work, I make such big mistakes.
But I will not continue this argument, since for me it is not a matter of principle.
But if there is an error and it is confirmed, then it is up to the author to correct or ignore it.
1 Like
I am doing that also for port 853 to block DoT
But if a client uses DoH not much you can do about save blocking of known DoH resolvers with e.g. BanIP
This is exactly what I was talking about! Adjust your expectations. If a client has enforce mode set, it will ignore Canary domains mechanism. It is intended behavior. Chrome knows nothing about Canary domains, so treat it as enforce mode and use BanIP if you want to block it. Dragging IP based blocklists to DoH proxy... - well, I don't think it is a good idea.
1 Like
Now I feel stupid because I don't understand what is the difference between Mozilla using DoH and Android using private DNS. Aren't they both encrypted and why the former couldn't be blocked but the latter could be blocked?
They both can be blocked. DoT (provided by Android for quite a long time) is the easiest to block because it runs on dedicated port 853. Block port 853 and you're done. DoH on the other hand runs on port 443 and looks like legitimate HTTPS traffic. In order to block it you have to block only specific IP adresses. Both protocols can't be downgraded (redirected) to regular DNS at port 53.
3 Likes
Thanks for the clarification, maybe the readme should be a little bit clearer about that because I expected that with the Mozilla specific only option set Mozilla shouldn't be able to use DoH to resolve domains. And I was really surprised it's not that way.
Probably you're right. A lot of things can be rephrased for better understanding what to expect.
Reading this article https://support.mozilla.org/bg/kb/canary-domain-use-application-dnsnet
I am still under the impression that Mozilla should not be able to use DoH with the Canary Domains setting set from Luci.
Only in its default settings. Some people still want to use DoH, that's why they made maximum security mode. Let's call it enforce for short.
Not really, only if your browser or client is instructed to check for the canary domain but that is configurable that is why you always have to use the redirection/blocking rules for port 53 and 853.
Beside this only covers DoT.
DoH clients usually do not check for canary domains as they are designed to circumvent any blocking that is why they use port 443 which cannot be blocked (well it can of course but that means not http(s) traffic so no "internet")
1 Like
Actually the opposite, it was designed for userspace DoH implementations - https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet.
Sorry it took a while to reply. Is this with the apk from the OpenWrt repo or from my repo?
It was from your repo. But as you updated it in main OpenWrt branch then I compiled a build and I have it already running.
Show the https-dns-proxy config. May be an issue with the luci app on storing custom bootstrap servers into config properly.