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

An important PSA for everyone using the https_dns_proxy package!

Aaron Drew, the maintainer for the original package has recently accepted the pull request to support RFC8484 resolvers and retire support for the outdated JSON API resolvers. That resulted in no longer compatible resolver urls (and no longer compatible OpenWrt config files). To avoid broken DNS resolution, the decision was made to rename the OpenWrt package from https_dns_proxy to https-dns-proxy which would use a different config file now (/etc/config/https-dns-proxy).

That also resulted in a significantly larger number of supported resolvers and the luci app (Web UI) lists the ones I've tried. Adding new resolvers to Web UI is easy and requires no changes of the code, as resolvers are pluggable (thanks to @feckert for the suggestion).

Both the https-dns-proxy and luci-app-https-dns-proxy have been merged in master, 19.07 and 18.06 trees and should be available as packages shortly.

Last but not least, existing Web UI translations have been preserved despite the package name change (thanks @hnyman), but there are many new resources, so I'd like to ask all the translators to update their translations!

README: https://github.com/openwrt/packages/blob/master/net/https-dns-proxy/files/README.md

8 Likes

I would appreciate general proofing/feedback on the README: https://github.com/stangri/openwrt_packages/blob/master/https-dns-proxy/files/README.md.

2 Likes

That was incredibly easy for someone who probably needed an ELI5 instruction guide before discovering this. Thanks!

Edit: It was spotty at first but I ended up turning off Use DNS servers advertised by peer in WAN and WAN6 settings.

How can I add the IPV6 addresses for cloudflare as well?

This will be automatically disabled for affected DNSMASQ instances on start in the next version (2019-12-03-4).

Please elaborate on your question.

This app is very well dun. Thanks stangri BTW the LUCI app is grate with my screen reader too.

1 Like

Another PSA: if you're using https-dns-proxy and experience memory/CPU hogs, do consider switching from wolfssl to either a newer version of wolfssl or openssl. Looks like there's an issue using wolfssl with https-dns-proxy.

1 Like

Is than an option? It looks like the opkg is directly dependent on libcurl4, which is in turn dependent on libwolfssl4.7.0.66253b90. I'm not sure there's any way to force libcurl4 to use openssl, is there?

Oh, you're right, I've noticed that libwolfssl is installed on my router, most likely due to dependency. But I also have the libopenssl and libustream-openssl installed, and never had any issues. Can you try the same and post back?

I don't think it's going to make much difference...it's definitely linked to wolf:

root@cerberus:~# ldd /usr/sbin/https-dns-proxy
        /lib/ld-musl-aarch64.so.1 (0x7f84018000)
        libcares.so.2 => /usr/lib/libcares.so.2 (0x7f83ff4000)
        libcurl.so.4 => /usr/lib/libcurl.so.4 (0x7f83f95000)
        libev.so.4 => /usr/lib/libev.so.4 (0x7f83f76000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f83f53000)
        libc.so => /lib/ld-musl-aarch64.so.1 (0x7f84018000)
        libwolfssl.so.4.7.0.66253b90 => /usr/lib/libwolfssl.so.4.7.0.66253b90 (0x7f83daf000)

root@cerberus:~# ldd /usr/lib/libcurl.so.4.7.0
        ldd (0x7f8a7c5000)
        libwolfssl.so.4.7.0.66253b90 => /usr/lib/libwolfssl.so.4.7.0.66253b90 (0x7f8a5c2000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f8a59f000)
        libc.so => ldd (0x7f8a7c5000)

root@cerberus:~# ldd /usr/lib/libwolfssl.so.4.7.0.66253b90
        ldd (0x7fa7c4c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fa7a85000)
        libc.so => ldd (0x7fa7c4c000)

You're right, didn't check that. I have no idea then why it's working fine on my system with exact same version of libwolfssl.