DoH proxy: https-dns-proxy new RFC8484-supporting package and Web UI

stangri · September 30, 2025, 11:00pm

Doesn’t seem to have HTTP3.

sppmaster · September 30, 2025, 11:23pm

Yep, maybe Curl Make file needs additional changes?

stangri · October 1, 2025, 12:01am

outside of scope of this thread.

sppmaster · October 2, 2025, 1:18pm

Yep, I agree, no need to spam here.
I've managed to compile Curl with http/3 support using OpenSSL with QUIC and it works.
I've made some tests that anyone interested in HTTP/3 (QUIC) support can see on the above link.
I no longer see the message that http/3 (Quic) is not supported on my build.
Now comes my question - how https-dns-proxy uses the HTTP/3 (QUIC) support.

stangri · October 2, 2025, 9:53pm

Unless the DoH resolver is HTTP/3 only, the daemon negotiates the protocol when connecting to server. As far as I remember, if you enable verbose logging you should see wherever HTTP/3 or HTTP/2 is being used.

stangri · October 7, 2025, 11:22pm

There was an update upstream to hopefully fix division by zero errors (which happened once and were impossible to replicate) and there’s a bunch of updates to the init file:

github.com/openwrt/packages

https-dns-proxy: update to 2025.10.07-r1

master ← stangri:master-https-dns-proxy

opened 05:07PM - 07 Oct 25 UTC

stangri

+197 -116

Maintainer: me Compile tested: x86_64, Dell EMC Edge 620, OpenWrt 24.10.3 Run …tested: x86_64, Dell EMC Edge 620, OpenWrt 24.10.3 Description: Makefile: * update to latest upstream: https://github.com/aarond10/https_dns_proxy/commit/7b27ecd5598d03bbe79651cc80efca886d433cd9 * update version, release * drop CONFIGURE_ARGS as the build is curl-independent * update the link to the documentation README: * add small README with the link to documentation Config: * rename procd_fw_src_interfaces to force_dns_src_interface to better reflect meaning * add heartbeat_domain, heartbeat_sleep_timeout, heartbeat_wait_timeout options * add default user, group and listen_addr options to the main config * drop the user, group and listen_addr options from the instance configs Init-script: * start much earlier so that on boot, the procd_add_raw_trigger works on all systems * create a ubus() helper function so that service delete does not produce "Command not found" * new options handling where the global config options can be used for instance options * some renaming of global/instance variables due to abovementioned redesign * new open port detection, no longer relying on netstat * new uci_changes() logic where it returns 0 or 1 instead of text * new append_parm logic for not adding default value options to CLI * new boolean options handling logic * move config loading to load_package_config() function * new logic for calling procd_set_config_changed firewall based solely on "$force_dns" * source network.sh based on "${IPKG_INSTROOT}" path * rename procd_fw_src_interfaces to force_dns_src_interface to better reflect meaning * rename use_http1 to force_http1 * rename use_ipv6_resolvers_only to force_ipv6_resolvers Uci-defaults: * migrate to new option names

github.com/openwrt/packages

[24.10] https-dns-proxy: update to 2025.10.07-r1

openwrt-24.10 ← stangri:openwrt-24.10-https-dns-proxy

opened 10:34PM - 07 Oct 25 UTC

stangri

+196 -115

Maintainer: me Compile tested: x86_64, Dell EMC Edge 620, OpenWrt 24.10.3 Run …tested: x86_64, Dell EMC Edge 620, OpenWrt 24.10.3 Description: Makefile: * update to latest upstream: https://github.com/aarond10/https_dns_proxy/commit/7b27ecd5598d03bbe79651cc80efca886d433cd9 * update version, release * drop CONFIGURE_ARGS as the build is curl-independent * update the link to the documentation README: * add small README with the link to documentation Config: * rename procd_fw_src_interfaces to force_dns_src_interface to better reflect meaning * add heartbeat_domain, heartbeat_sleep_timeout, heartbeat_wait_timeout options * add default user, group and listen_addr options to the main config * drop the user, group and listen_addr options from the instance configs Init-script: * start much earlier so that on boot, the procd_add_raw_trigger works on all systems * create a ubus() helper function so that service delete does not produce "Command not found" * new options handling where the global config options can be used for instance options * some renaming of global/instance variables due to abovementioned redesign * new open port detection, no longer relying on netstat * new uci_changes() logic where it returns 0 or 1 instead of text * new append_parm logic for not adding default value options to CLI * new boolean options handling logic * move config loading to load_package_config() function * new logic for calling procd_set_config_changed firewall based solely on "$force_dns" * source network.sh based on "${IPKG_INSTROOT}" path * rename procd_fw_src_interfaces to force_dns_src_interface to better reflect meaning * rename use_http1 to force_http1 * rename use_ipv6_resolvers_only to force_ipv6_resolvers Uci-defaults: * migrate to new option names (cherry picked from commit a2ac6ff122b212c97620dd1d34c4b54dc4233ed2)

fantom-x · October 10, 2025, 12:30pm

Not sure shat happened. I have just built a new image (using image builder) from 24.10-SNAPSHOT and https-dns-proxy is now disabled by default.

/etc/init.d/https-dns-proxy enabled ; echo $?
1

find /etc/ -name "*https-dns-proxy*"
/etc/config/https-dns-proxy
/etc/init.d/https-dns-proxy

From image builder logs:

Enabling https-dns-proxy

It was a fresh install without preserving config.

UPDATE: I just check during the build and the soft links for https-dns-proxy are not created by the image builder:

ls -la ./build_dir/target-x86_64_musl/root-x86/etc/rc.d/ | grep dns
lrwxrwxrwx  1 buildbot buildbot   17 Oct  9 21:16 S19dnsmasq -> ../init.d/dnsmasq

Nullity · October 10, 2025, 1:25pm

Same thing just happened to me.
Had to re-enable & start https-dns-proxy after flashing new imagebuilder image.

fantom-x · October 10, 2025, 1:31pm

@stangri this happens because of this change below: that line should be using return.

Here is how to reproduce this issue on a working router:

/etc/init.d/https-dns-proxy disable

find /etc/ -name "*https-dns-proxy"
/etc/config/https-dns-proxy
/etc/init.d/https-dns-proxy

export IPKG_INSTROOT="/"

/etc/init.d/https-dns-proxy enable

find /etc/ -name "*https-dns-proxy"
/etc/config/https-dns-proxy
/etc/init.d/https-dns-proxy

unset IPKG_INSTROOT

/etc/init.d/https-dns-proxy enable

find /etc/ -name "*https-dns-proxy"
/etc/config/https-dns-proxy
/etc/init.d/https-dns-proxy
/etc/rc.d/S20https-dns-proxy
/etc/rc.d/K15https-dns-proxy

If IPKG_INSTROOT is set (like it is in image builder), then /etc/init.d/https-dns-proxy exits instead of return’ing. If IPKG_INSTROOTis NOT set, then the service can be enabled.

If I undo the change above in the script, then it all works in both cases.

stangri · October 10, 2025, 7:51pm

@fantom-x @Nullity will be fixed and update pushed shortly.

fantom-x · October 11, 2025, 12:00pm

Did you mean to keep the version number the same…

Sid · October 11, 2025, 3:35pm

@stangri since option listen_addr is now a global setting instead of instance specific, why can’t we add another listener like 0::1 for ipv6 too?

stangri · October 13, 2025, 1:28am

You can either set it globally or in the instance config, just like before. Instance config overrides global (if both are set).

AFAIK upstream only allows one listen address per instance. Maybe run two instances one each on legacy/IPv6?

Sid · October 14, 2025, 2:00am

Maybe run two instances one each on legacy/IPv6?

In this case the listen ports should be kept the same? Since new instance uses a new port.

Something like this?

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_port '5053'

config https-dns-proxy
        option bootstrap_dns '2606:4700:4700::1111,2606:4700:4700::1001'
        option resolver_url 'https://cloudflare-dns.com/dns-query'
        option listen_port '5053'
        option listen_addr '::1'

stangri · October 15, 2025, 7:27pm

if you manually specify servers for dnsmasq to point it to https-dns-proxy instances, you can try keeping the same port.

If you let https-dns-proxy manage dnsmasq settings, it will point dnsmasq to whatever ports it sets.

fantom-x · October 19, 2025, 12:32pm

If dnsmasq only allowed one address, why are there multiple config https-dns-proxy sections? What is the purpose of the second one in the default config?

I thought that the second section would allow me to handle IPv6 DNS, but it does not seem to be the case. Can you clarify?

stangri · October 19, 2025, 4:29pm

Sorry should have been more explicit – upstream as in upstream project, not upstream resolver.

fantom-x · October 19, 2025, 4:46pm

I have configured two instances of https-dns-proxy: one for IPv4 and one for IPv6. Restarted https-dns-proxy and can see them in /etc/config/dnsmasq. One strange thing I noticed is that the IPv6 service came up without bootstrap_ip, even though it is configured: is that expected.

 	list server '127.0.0.1#5053'
 	list server '::1#5054'

/usr/sbin/https-dns-proxy -r https://dns.controld.com/x -p 5053 -b x.x.x.x -4 -u nobody -g nogroup
/usr/sbin/https-dns-proxy -r https://dns.controld.com/x -a ::1 -p 5054 -4 -u nobody -g nogroup

stangri · October 19, 2025, 5:06pm

Are they the IPv6 bootstrap addresses? If there’s a family mismatch, the offending bootstrap addresses are silently dropped.

fantom-x · October 19, 2025, 7:15pm

Yes

config https-dns-proxy
 	option bootstrap_dns 'x.x.x.x'
 	option resolver_url 'https://dns.controld.com/y'
 	option listen_port '5053'
 	option listen_addr '127.0.0.1'

config https-dns-proxy
 	option bootstrap_dns 'x:x::x'
 	option resolver_url 'https://dns.controld.com/y'
 	option listen_port '5054'
 	option listen_addr '::1'