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

Community Builds, Projects & Packages
214

I noticed that latest https-dns-proxy version installed from the repo is: 2023.12.26-1 while the luci-app version installed is 2025.12.29-3 Is it the same for everyone? I’m still on 23.05 btw, not sure if that is related

215

2025.12.29-r1 on uCI openwrt-24.10 branch (26.015.62384~5f98c11) / OpenWrt 24.10.5 (r29087-d9c5716d1d)

1 Like
216

@reflector you may want to enable and grab instance logs and seek help from aarond10 who is the creator of the https_dns_proxy package and/or NextDNS support/Oliver, although I suspect they would steer you to their NextDNS package for OpenWrt. I can’t really help you figuring out why, despite the OpenWrt support, the HTTP/3 is still not being used.

@fdauti most of the luci app issues are due to the browser caching old javascript. Clear the cache, use incognito mode, use different browser – either of these should work.

The binaries of the new versions are available under Releases at the https://github.com/stangri/https-dns-proxy. The OpenWrt 23.05 packages haven’t been updated with the new builds for a while and as soon as the 25.12 is out, outside of vulnerabilities, I won’t be updating 24.10 packages with the new builds either. That doesn’t stop anyone else from creating a pull request against an outdated branch, but I won’t be doing that.

@Ityns I wouldn’t say it’s unmaintained, it has no dedicated active maintainer.

3 Likes
217

Yes, i tried to udpate to the nes httpsdnsproxy version from github repo but it doesnt work on 23.05, so i will keep using the old version for now, until i update openwrt

218

Well, lack of a dedicated active maintainer is pretty bad in case of curl due to security vulnerabilities.

219

well, maybe create a dedicated curl thread rather than clutter this one? :wink:

3 Likes
220

I’m migrating to a new router and noticed a difference in the bootstrap DNS being used with the built in providers. For clarity I am not sure if it was a custom config I used previously or if the built in defaults have changed.

Here is the config used previously (again, not sure if generated or manually entered):

config https-dns-proxy
        option bootstrap_dns '1.1.1.2,1.0.0.2'
        option resolver_url 'https://security.cloudflare-dns.com/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 '9.9.9.11,149.112.112.11'
        option resolver_url 'https://dns11.quad9.net/dns-query'
        option listen_addr '127.0.0.1'
        option listen_port '5054'
        option user 'nobody'
        option group 'nogroup'

And here are the new ones, if I create them via the UI:

config https-dns-proxy
        option resolver_url 'https://security.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 listen_port '5053'

config https-dns-proxy
        option resolver_url 'https://dns11.quad9.net/dns-query'
        option bootstrap_dns '9.9.9.9,149.112.112.112,2620:fe::fe,2620:fe::9'
        option listen_port '5054'

My layman understanding is that previously, the “appropriate” DNS bootstrap was used (so 1.1.1.2 since I’m using cloudflare security).

I suppose the point is that it doesn’t matter, since we are only looking up the resolver_urls using the bootstrap anyway? But just confirming there wasn’t a reason it was set more elaborately before.

221

Exactly :slight_smile:

It now also uses IPv6, not sure if that is set if you have IPv6 enabled or if it is always set.

3 Likes