This is not normal and usually is an indication the 127.0.0.1#5053 entry was added manually when https-dns-proxy was stopped.
Are you saying this is a config from a freshly flashed OpenWrt image with https-dns-proxy baked in?
There are also no non-encrypted servers defined, how is your DNS resolution supposed to work when https-dns-proxy is stopped/starting?
It looks like:
your original dhcp config (unmodified by https-dns-proxy) doesn't have resolvers defined at all, are you setting up resolvers in the network config?
your original dhcp config has an incorrect entry for 127.0.0.1#5053 which wouldn't work until https-dns-proxy is started
it will take the output of logread -ehttps on a freshly rebooted system to confirm, but looks like on boot the https-dns-proxy fails the resolver health check and shuts down; it should then be restarted on any interface up trigger, I have no idea why on your system it's not restarted automatically
Might be this scenario?
Firmware with DoH proxy setup
New firmware keeping settings but without DoH proxy, old settings are still there.
As it does not work, another firmware now with DoH proxy, this will see existing settings
As I said before, I reset the router every time I flash a new firmware and reconfigure it again with commands (although the most important ones I already shared above, because the others are to change the IP address of the LAN interface, add DNS to the WAN interfaces and add static IP addresses).
Sorry but I've had enough, this is my last post and I think one of these is the culprit:
Maybe the option in https-dns-proxy about automatic update for dnsmasq configuration is broken and is the cause of the DNS leak.
Every time I reboot the router it shows the IP "192.168.100.2" and after a few seconds it tries one or more times to request an address via DHCP and then it changes to "190.xx.206.xx1" or "190.xx.239.xx2", etc. and I think that's where the problem occurs.
You can see in the dhcp configuration above the option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto' and always that is the last one to appear in the log I have DNS Leak:
Reading this exchange today made me realize that my config has also been corrupted. I have a different second port than 5054 (I think it was 5342 and that port seems to originate within the NextDNS app), but I know it was 5054 originally.
Also have two "backup servers" listed. I know I didn't add these things manually but I'm 99% sure in my case it was the NextDNS app that runs concurrently that made the changes. Though I may have set the the flags on the app to do so?
I'm also missing a few of the lines in the config you posted, gonna try and clean things up. Hoping this will address almost 50% of the network traffic bypassing the local DNS (Apple and Amazon using quic mostly).
Edit: appending the code
Port 5342 comes from nextdns.conf which is pointed to in config dnsmasq as option confdir '/tmp/dnsmasq.d'^
additions to config dnsmasq that weren't done manually:
list doh_server '127.0.0.1#5053'
list doh_backup_server '127.0.0.1#5053'
list doh_backup_server '/mask.icloud.com/'
list doh_backup_server '/mask-h2.icloud.com/'
list doh_backup_server '/use-application-dns.net/'
It's safe to delete this line. If you've been using https-dns-proxy for 2 years or longer, there was a mangled release I pushed in OpenWrt repo and which stayed there for a few weeks, which would erroneously not remove the dhcp server entries for stopped https-dns-proxy instances, which would on next start result in the extra entry like above.
I love this plugin. Has been working great for me for a while. But as I have been migrating my network from a flat layout to a VLAN segregated design, I have noticed something with the firewall rules that could use improving.
I've got my own workaround in place already, but had a few thoughts on how you might improve.
The luci package could use at the very least an indication that it is only active on the default 'lan' and that you should configure via uci the procd_fw_src_interfaces setting. A multi-select drop down of some sort would be ideal.
The rules that get created for the override to capture DNS lists the ports which is nice, but unfortunately they drop in at the TOP of the list which means they will always override any manually configured traffic rules in luci. This was unexpected. I have a service in a VLAN that is running on port 8443 and need my lan device to reach it an so gets caught by the blanket forward rule. If it populated at the bottom of the list my manually entered rule could allow the specific traffic I need and still work as intended.
My work around for now was to remove 8443 from the procd port list and to manually create that rule.
This has me thinking though that perhaps the rules shouldn't be on the source networks but perhaps blocked on the wan or vpn output chains as it might result in less rules for typical networks? Just an idea.
That port is not in the default configuration. If you have any ports you want to manage manually, especially if they overlap with the ports you want to hijack, you should consider doing everything manually and disabling the hijacking in the https-dns-proxy.
Thanks for your feedback, I'll consider adding more information about it in the option description and link to the README with more details. README is in a public repo, so if you want to contribute a section there, you're more than welcome to send a PR. I'm very strongly against overloading UI with another option for less than 1% of users of the package which rename/need to alter the LAN name.
I'm not really sure where it came from to be honest perhaps it was carried over from a much older implementation of the package or maybe I added it myself a while back and forgot. Regardless, I think it's worth considering how they override any manually configured rules due to injecting at the top. First match always wins and so if they could be appended to the ruleset that would make for a better user experience in my opinion.
Using dnscheck.tools I get this message
"Your DNS resolvers provide partial client IP address information (ECS):"
Does anyone have an idea how this can be mitigated so the privacy info is not leaking.
It's obviously due to Google DNS service. I'll switch to Quad9. Anyone knowing what settings should be used for Quad9.
Does using default settings for Cloudflare and Google include IPv6 by default.
It seems so but I ask because in settings there are IPv4 addresses only.
Suppose this is good
Perhaps it is worth considering enforcing strict-order in dnsmasq when this package is used? Otherwise putting the servers in any particular order (in LuCI, at least) is rather pointless.
I find it handy to put my ad-blocking-resolver-of-choice at the top and leaving the standard resolvers below for the best of all possible worlds - maximum protection when available with a fail-open automatic fallback.
While it certainly is the case when using ad-blocking resolvers, I feel that most people use this package to just encrypt the DNS requests by using major players DNS resolvers (like google, cloudflare, quad9, etc.) so for them it would be of no benefit, because generally speaking they want the reply as fast as possible.
It would make a lot of sense to add a note about strict-order setting for dnsmasq in the section of the README which covers use of this package for ad-blocking, so thank you very much for bringing this up, I'll try to address in the very near future.
PS. I want to keep the init script as simple as possible, so I've looked into adding a warning to the luci app, but because again the init script is a very simple code, it doesn't add any warnings/errors messages to ubus, so the luci app isn't coded to display any errors/warnings either. I can totally copy the javascript and rpcd code for warnings from my other applications, but it's a bigger endeavour than just quickly displaying one message. I may have to think over how to best display a warning if a strict-order is not enabled on selected dnsmasq instances while ad-blocking resolvers are used. For now I've just added this information to the README.
The same luci app and principal https-dns-proxy app will support HTTP/3 if the HTTP/3(QUIC)-supporting curl is installed, so there's no need for separate packages.
Also there's no way for the package in the OpenWrt repo to depend on the package outside of the repo.
I'm testing https-dns-proxy with a bunch of providers (well i guess i added a lot as you can see below).
How many do you stick with, considering that each seem to use 2% of RAM constantly - though I'm not sure why all of them if only 2 will get selected to be used at anytime (probably i don't understand well how it works)
Second question is, what is the line -b 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4 used for, considering those are cloudflare and google dns (i have removed google form the list of providers). Is this used as some kind of benchmark?
Btw, i use the package to encrypt DNS request cause ISP blocks IPTV servers (ISP also block Notion website cause it uses .so lol). This way I can avoid using a VPN, since DoH is enough to get iptv service, plus DoH should be faster than VPN. So basically i need the fastest DoH provider possible at anytime.
How do I add NordVPN DNS servers as custom entry in this package? I tried through custom and then adding 103.86.96.100 in BootStrap DNS field but it didn't worked, it wasn't picked. Maybe I should look elsewhere, in PBR or DNS Forwards
Does Nord VPN has a DoH DNS server if so you need to have the domain address.
I think the DNS53 DNS servers from Nord are only available via the VPN tunnel this will end up in a catch 22 situation as to start the VPN tunnel you need DNS resolving first and that is not available as the DNS server only works via the tunnel so you can not use the NordVPN as bootstrap servers