If you're willing to contribute the "native IPs" for the DoH resolvers that don't have them -- be my guest.
I can help gather the correct native IPs for the rest of the missing providers if we are doing this database cleanup.
If I were a programmer, I'd just automate this to run automatically before every new plugin release.
That way, the database would always have fresh IPs, eliminating the need for unencrypted queries. The plugin could just go straight to the encrypted channel, cutting out all cleartext lookups entirely—even if they aren't inherently dangerous.
So your concern is that if you wanted to use "BlahDNS" as your resolver, that the initial lookup for "BlahDNS.dns .net" might be resolved by some other DNS provider?
Just add a local host entry for the FQDN so it gets resolved to IP locally instead of externally.
Or, you could also do it under Network>DNS> General Tab
2 Likes
But to do that, this plugin isn't needed. The whole beauty of this plugin could have been doing this visually, simply, and preferably without transmitting data over unencrypted channels at all. But if not, then — NO.
new version has been released v2026.05.06-1.
where can i find the changelog and is it mandatory to update i'm already using v4 and i believe it is working fine.
That is in the commit messages when it is committed to the OpenWRT repo, only that has yet to happen.
So it is not officially out for OpenWRT yet.
Of course you are welcome to try it and report, you can view the commits what has been changed:
3 Likes
I see logread example:
on Jul 13 14:15:16 2026 daemon.info https-dns-proxy[30460]: [I] 1783926916.281589 https_client.c:521 3C0C: Response was faulty, skipping DNS reply
Mon Jul 13 14:15:16 2026 daemon.info https-dns-proxy[30460]: [W] 1783926916.281709 https_client.c:364 30BF: curl request failed with 16: Error
Mon Jul 13 14:15:16 2026 daemon.info https-dns-proxy[30460]: [W] 1783926916.281729 https_client.c:380 30BF: Connecting and sending request to resolver was successful, but no response was sent back
Mon Jul 13 14:15:21 2026 daemon.info https-dns-proxy[30460]: [I] 1783926916.281745 https_client.c:521 30BF: Response was faulty, skipping DNS reply
Mon Jul 13 14:15:44 2026 daemon.info https-dns-proxy[30460]: [W] 1783926944.880795 https_client.c:364 DDD4: curl request failed with 16: Error
Mon Jul 13 14:15:44 2026 daemon.info https-dns-proxy[30460]: [W] 1783926944.880875 https_client.c:380 DDD4: Connecting and sending request to resolver was successful, but no response was sent back
Mon Jul 13 14:15:51 2026 daemon.info https-dns-proxy[30460]: [I] 1783926944.880896 https_client.c:521 DDD4: Response was faulty, skipping DNS reply
Mon Jul 13 14:16:23 2026 daemon.info https-dns-proxy[30460]: [W] 1783926983.349730 https_client.c:364 E98A: curl request failed with 16: Error
Mon Jul 13 14:16:23 2026 daemon.info https-dns-proxy[30460]: [W] 1783926983.350108 https_client.c:380 E98A: Connecting and sending request to resolver was successful, but no response was sent back
That is normal or abnormal ? My dns-proxy resolution work ok.
Here https-dns-proxy config:
/etc/os-release
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r35210-8614a2ba68"
OPENWRT_BUILD_DATE="1783207215"
/etc/config/https-dns-proxy
config main 'config'
list force_dns_port '53'
list force_dns_port '853'
option dnsmasq_config_update '*'
option notrack_dns '1'
option procd_trigger_wan6 '0'
option listen_addr '127.0.0.1'
option verbosity '2'
option user 'nobody'
option group 'nogroup'
option heartbeat_domain 'heartbeat.mossdef.org'
option heartbeat_sleep_timeout '10'
option heartbeat_wait_timeout '10'
config https-dns-proxy
option resolver_url 'https://cloudflare-dns.com/dns-query'
option bootstrap_dns '1.1.1.1,1.0.0.1,2606:4700:4700::1111,2606:4700:4700::1001'
option verbosity '2'
option listen_port '5053'
config https-dns-proxy
option resolver_url 'https://dns.google/dns-query'
option bootstrap_dns '8.8.8.8,8.8.4.4'
option verbosity '2'
option listen_port '5054'
config https-dns-proxy
option resolver_url 'https://dns.quad9.net/dns-query'
option bootstrap_dns '9.9.9.9,149.112.112.112,2620:fe::fe,2620:fe::9'
option verbosity '2'
option listen_port '5055'
config https-dns-proxy
option resolver_url 'https://dns.adguard-dns.com/dns-query'
option bootstrap_dns '94.140.14.140,94.140.14.141'
option verbosity '2'
option listen_port '5056'
Which instance is running as process 30460? Maybe that one has issues (wouldn’t be surprised if it is the quad9 one)?
2 Likes
Yep, that's Quad9. I switching to a different resolver and no longer see those error messages.
1 Like
You are not the only one experiencing this.
I use Cloudflare and Google and ditched quadnine
BTW I think those are the defaults
1 Like
I wonder if that depends on protocol used. I use quad9 on one location with DNSCrypt (dnscrypt-proxy2) and have no complains about their service.
1 Like
In this case we are specifically talking about https-dns-proxy
See also: https://github.com/aarond10/https_dns_proxy/issues/203
1 Like
... but if I don't see it on their DNSCrypt service that can help to pinpoint faulty component of their infrastructure.
Sure, what I meant is that I cannot speak of anything other then https-dns-proxy, as you pointed out other encrypted DNS will work with quad-nine.
@reinerotto has been researching this subject, I did not follow it up, I simply removed quad-nine 
Can https-dns-proxy handle DNS requests not only from the LAN interface but also from WireGuard (WG) interfaces? Or is this completely out of scope for this plugin, and I should look for other alternatives?
Currently, if a client (whether it's another router, a phone, or a tablet) connects to the router via WG, its DNS requests seem to bypass the DoH proxy. This causes DNS leaks, exposing the requests in plaintext and compromising privacy. This is not good!
Is there a proper way to force WG clients through the proxy using this plugin, or does it only intercept standard LAN traffic?
Do you mean WireGuard clients connecting to your router which serves as a WireGuard server?
Question to script maintainer or other.
I'm using https-dns-proxy together with pbr and it's working with some problems.
I have setup second dnsmasq to get dnssec working as recommended but it has some quirks.
Maby there is some other way to do it!
Is it possible to get som guidens to set it up properly?
It must'nt be a complete guide. Something I can start with and mange myself.
100500% True
I currently have three WG interfaces. I'd like to prevent DNS leaks from them.
Almost all WG clients have a DNS setting if you set that to the routers address, where DNSMasq is listening then your WG clients should use DNSMasq, which in its turn uses HTTPS-DNS-Proxy.
Two things to check in DNSMAsq:
The first is to make sure that the DNS server can actually process your queries.
DNSMasq has to listen on all interfaces so also on the WG interface, by default this is the case but if you changed that then you have to add the WG interface as listen interface.
The second is that DNSMasq has to answer non local request.
For this disable Local Service only (DNSMasq: -local-service):
Luci DNS-DHCP > Filter >Local service only : untick/disable, \
or in /etc/config/dhcp:
config dnsmasq
```
option localservice '0'
```
If you want to also enable Force DNS for the WG server interface then see the read.me
This will lead you to:
force_dns_src_interface
This option allows you to override the interface (lan by default) which is used in the PROCD firewall redirects/rules the service creates if force_dns is enabled. Only needed if you have renamed or deleted your lan interface. If you indicate more than one interface, separate them by spaces.
2 Likes
Thanks for the explanation.
I understand the logic, but I still believe that a 100% GUI-based configuration is the way to go.
It’s significantly more convenient for managing complex setups. After all, OpenWrt already has this standard for other services where you can simply pick interfaces from a dropdown list or check-boxes. It would be great to have the same user-friendly approach here as well.