Is that what the base OpenWrt repo on ipq807x is configured for? The wrong architecture should not install on your router, so it’s safe to try.
1 Like
It doesn’t install on ipq807x target.
There’s a bugfix from baranyaib90 in version 2025.09.11-r1 available from https://github.com/stangri/https-dns-proxy/releases/tag/v2025.09.11-1
This should fix occasional division by 0 messages in dmesg. We both would appreciate if you could install and test the update before it gets merged upstream/to OpenWrt repo.
1 Like
I cannot test it because even if I replace Makefile in /feeds/packages/net/https-dns-proxy/
it doesn’t compile for ipq807x target.
Is there a PR for it so I can try compiling it.
ipq807x is Cortex A53 have you tried to install:
https-dns-proxy-2025.09.11-1_snapshots_aarch64_cortex-a53.apk
2 Likes
Yea, thanks, my stupid oversight.
It installed and I will test it.
1 Like
@stangri I try to test the newest r1 build although I currently have an issue with dnsmasq that I can’t resolve at the moment. The domain resolving is really slow sometimes or doesn’t work at all.
Anyway I tried to stop https-dns-proxy to see if that will help with dnsmasq issue. It didn’t but I found out that when I stop https-dns-proxy it didn’t restore the dnsmasq settings.
Those are still there.
Edit - my latest findings show that currently maybe both pbr and https-dns-proxy caused the dnsmasq issues at least on my hardware with my settings.
Update 2 - I’ve enabled https-dns-proxy again (pbr remains disabled) to try it alone.
No issues with it currently, dnsmasq working OK, no high CPU usage, nor errors in the log.
Hey guys, please help me to understand this right way.
I have guest network on separate subnet and want devices from that network to use DOH also, I see that only LAN interface using this proxy by default. BUT when test DOH on guest network devices it’s active.
I have firewall rule for allowing DNS input on port 53 from guest network so maybe that’s the reason it’s working even if I didn’t add ‘guest’ interface into config?
By default, the DoH proxy will be set as the upstream server for all dnsmasq instances, so as long as the guests can reach the router for DNS queries, they will pass through the DoH proxy.
2 Likes
Got it, thank you!
One more quiestion: If I add multiple DNS providers (in luci) are they used from top to bottom priority? Or only first one is used and rest are backup?
dnsmasq will forward to the fastest one, and it will check all the upstream servers every 50 queries or every 20 seconds, whichever comes first. So if you use different servers but one is measurably slower than the other (e.g. Cloudflare versus Quad9), it is less likely to be used by dnsmasq.
3 Likes
Awesome, thank you!
Are those constant dns speed checks affects performance in some way? Is it better to use one server and add reliable backup server in the config file? haha sorry for nitpicking
No, it's meant to improve performance by favoring the fastest server. This has been standard dnsmasq behavior for a long time, unless strict-order is part of the dnsmasq configuration.
I'm relatively new to https-dns-proxy so to be safe, I setup duplicate servers both pointing to Cloudflare Security in case either process had an issue. In theory they should be giving me the same response times from dnsmasq's perspective.
3 Likes
Everything clear, thank you!
The statement that only LAN interface is using this proxy by default is incorrect.
If you meant that the force dns is only being active on LAN by default, you can configure which interfaces to force router’s DNS onto by setting the force_dns_src_interface option.
Just to add to @dave14305 s answer: it’s up to the resolver (dnsmasq by default) on how to use those proxy servers. You can configure dnsmasq to enforce order or use the fastest as per @dave14305 explanation.
If your primary instance has any sort of filtering (ad-blocking or family filter, etc) but the backup/alternative instances do not, I’d recommend you configure dnsmasq to follow strict order, otherwise you can occasionally get unwanted domains resolved.
2 Likes
One word of warning strict-order is not very reliable it gives up rather quickly so slow dns servers might still be skipped
3 Likes
Seeing this message on my current snapshot build.
Just want to ask, are we ready for http/3 QUIC?
Currently there is a PR to enable it in OpenSSL.
But is this enough or there are additional changes to be made? Curl, libcurl maybe?
Maybe this info about HTTP/3 (QUIC) support is a bit outdated now?
@stangri @egc
Update - I applied the PR and enabled QUIC support in OpenSSL and HTTP/3 in libcurl and recompiled my build. Now I have this
root@Asus:~# apk info --depends libcurl
libcurl4-8.15.0-r1 depends on:
ca-bundle
libc
libnghttp2-14
libnghttp3
libngtcp2
libopenssl3
libpthread
zlib
libcurl4-8.15.0-r1 depends on:
ca-bundle
libc
libmbedtls21
libnghttp2-14
root@Asus:~# apk info --rdepends libcurl
libcurl4-8.15.0-r1 is required by:
https-dns-proxy-2025.09.11-r3
curl-8.15.0-r1
libspeedtestcpp-1.20.3-r1
but I still see the message HTTP/3 (QUIC) is not supported. Why? Can I test it?
1 Like
what’s the output of curl -V?
Since I dropped maintainership of curl after some curl-unrelated drama, I haven’t been keeping up with the status of HTTP3 support on OpenWrt, sorry, no help here.
See if you can grab relevant binaries from: https://github.com/sbwml/openwrt-curl-prebuilt
root@Asus:~# curl -V
curl 8.15.0 (aarch64-openwrt-linux-gnu) libcurl/8.15.0 OpenS
SL/3.5.3 zlib/1.3.1 nghttp2/1.66.0
Release-Date: 2025-07-16
Protocols: file ftp ftps http https mqtt
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Larg
efile libz SSL threadsafe UnixSockets