Yeah, nordVpn doesn't have a DoH Server
If I use the Nordvpn app with custom dns server, like Cloudflare, it will pick up the dns server location closes to the Nordvpn IP.
With Nordvpn connection through Openvpn in the router, using Pbr and https-dns-proxy packages, if I chose Cloudflare in https-dns-proxy, I get the server closer to the WAN IP location, not the NordVPN one. Yes, the WAN is the default service gateway in PBR. Is there an option to change that, or it will just use the WAN IP as the default location clue.
There seems to be a hard to catch bug between dnsmasq and https-dns-proxy so that I would get no name resolution from dnsmasq (happens maybe once or twice a week) although both services appear to work fine.
Had to make a script that calls /etc/init.d/https-dns-proxy restart when that happens.
And unfortunately had no success catching when or why it happens.
1 Like
You could try to force the https-dns-proxy traffic to the VPN tunnel, I'd experiment with creating the policy for the output chain targeting remote port 443 and see if that works.
However, if your VPN tunnel is down, it would prevent DNS resolution and (unless otherwise configured) access to NTP servers without which, on devices without the built-in clocks, the WG connections can't be established.
There used to be an issue where on some WAN interface updates the https-dns-proxy needed to be restarted and I thought I fixed that.
I'm using a OpenVPN, PBR and HttpsDns Proxy packages. Though I have selected one of the DNS DoH servers form Germany, that line I have pointed which has to do with ECS (something called EDNS Client Subnet) points to my actual ISP. Is that something I can do to prevent or change that?
The site I'm doing the checking (www.dnscheck.tools) is set under VPN gateway in PBR , so it correctly detects the VPN IP and DoH server set through DoH proxy. Just from where does that thing with ECS that points to my ISP leaks from (maybe location check, wan IP)?
I had the same issue and I just switched to a DNS that doesn't use ECS. Some DNS providers use different servers (different IP addresses) with or without ECS support.
1 Like
Side note: I looped through all the DoH providers in this package while connected with OpenVPN and noticed these ones didn't work: dnsflify, ahadns regional, idnet, applied privacy, restena, rubyfish, snopata .... maybe it was just me or they have introduced changes in their urls
1 Like
I'd test without the VPN, because they may block connections from VPN IPs pretty easily. Also, some regional providers (isn't rubyfish in china) may not resolve some domains blocked in those regions or accept out-of-region connections as well.
I think forcing router DNS is better, because it checks if the port on the router is open to redirect or to drop if it's closed. But you're welcome to leave your manual rules in, they do not interfere with the https-dns-proxy operations.
1 Like
I'm digging around in my router (23.05.5) and I've had http-dns-proxy installed for quite some time and it doesn't seem to work. Using the DNS leak and DNSSEC links at https://openwrt.org/docs/guide-user/services/dns/doh_dnsmasq_https-dns-proxy the DNS leak tests seem to pass but DNSSEC links fail.
My config is as follows:
/etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option ednspacket_max '1232'
option confdir '/tmp/dnsmasq.d'
list server '127.0.0.1#5053'
list server '127.0.0.1#5054'
list server '/mask.icloud.com/'
list server '/mask-h2.icloud.com/'
list server '/use-application-dns.net/'
option doh_backup_noresolv '-1'
option noresolv '1'
list doh_server '127.0.0.1#5053'
list doh_server '127.0.0.1#5054'
list doh_backup_server '127.0.0.1#5053'
list doh_backup_server '127.0.0.1#5054'
list doh_backup_server '/mask.icloud.com/'
list doh_backup_server '/mask-h2.icloud.com/'
list doh_backup_server '/use-application-dns.net/'
/etc/config/https-dns-proxy
config main 'config'
option canary_domains_icloud '1'
option canary_domains_mozilla '1'
option dnsmasq_config_update '*'
option force_dns '1'
list force_dns_port '53'
list force_dns_port '853'
option procd_trigger_wan6 '0'
config https-dns-proxy
option bootstrap_dns '74.82.42.42,2001:470:20::2'
option resolver_url 'https://ordns.he.net/dns-query'
option listen_addr '127.0.0.1'
option listen_port '5053'
option user 'nobody'
option group 'nogroup'
config https-dns-proxy
option bootstrap_dns '1.1.1.1,1.0.0.1'
option resolver_url 'https://cloudflare-dns.com/dns-query'
option listen_addr '127.0.0.1'
option listen_port '5054'
option user 'nobody'
option group 'nogroup'
Incidentally, contrary to remarks by @stangri, I just ran service log restart; service dnsmasq restart; service https-dns-proxy restart and the writing of the doh_backup_server lines did add the 127.0.0.1#5353 and 127.0.0.1#5354 lines. I had made sure that that any previous occurances of such were removed per comments earlier in the thread. If they're not supposed to be written, evidently the bug still exists. Currently, https-dns-proxy 2023.12.26-1 is installed which appears to be current from the opkg archive.
It's more complicated than that. In order for the testers to work, you must use the exact DNS provider tester you have set up in DNS. And if you have several, they probably switch and then basically no tester will show you the correct result. It additionally matters whether you use DNSCrypt or DoH protocol (they are different, I don't know which one https-dns-proxy uses).
1 Like
Thank you.
That makes sense even though it's not well communicated by the testing sites.
restart_https_dns_proxy @ 2025-02-10 21:08:48
restart_https_dns_proxy @ 2025-02-14 14:17:33
restart_https_dns_proxy @ 2025-03-02 00:09:32
restart_https_dns_proxy @ 2025-03-04 02:35:44
restart_https_dns_proxy @ 2025-03-13 10:35:55
restart_https_dns_proxy @ 2025-03-14 14:13:49
Here is the past month's log of how often it happens, not that it may be of any use, just shows that these are rare.
And there were no WAN disconnects.
And the script just checks in a loop nslookup google.com 10.0.0.2 and on "connection timed out; no servers could be reached" runs /etc/init.d/https-dns-proxy restart
Can I use the Firmware Selector to add HTTP/2 + HTTP/3 (QUIC) Support ?
I am using a TP-Link ER605 v2 and the ZyXEL WSM20 (“Multy M1”)
Click on more information link and you'll know.
I can't get http/3 to work... Is it enough to add certain packages or do I have to build my own image under my own development environment?
Many thanks in advance
You have to build....search the forum and you'll see the detailed process
I think actually it's a little more complicated than just compile your own build because of the need to compile curl with HTTP/3 support using the out-of-tree fork of OpenSSL.
1 Like
