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

Community Builds, Projects & Packages
1

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

9 Likes
2

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
3

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?

4

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

Please elaborate on your question.

5

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

1 Like
6

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
7

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?

8

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?

9

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)
10

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.

11

I've updated the WebUI to properly process HTTP/2-only resolvers (with version 2021-07-29-1). On most OpenWrt installs, curl doesn't support HTTP/2 (yet) so there would be no big changes.

If you have a custom libcurl build or custom OpenWrt build with HTTP/2 support in libcurl, I'd appreciate testing. You will then see extra HTTP/2-only resolvers in the list.

Thanks @bobafetthotmail for the PR suggestion!

12

If anyone is on 21.02 or snapshots and you can compile a package, please test 2021-09-27-2 from my repo (or just edit the init file on your system and delete the iface hotplug file: https://github.com/stangri/source.openwrt.melmac.net/commit/67353c1db593354b3d62cb5631f0b4763c7a291a).

14

The WebUI shows the instances sorted by the instance ID (not by any of the instance options). If you have manually changed the port number of the first instance to be higher than that of the second instance, that's how things will be shown.

If you had just checked the README and omitted the port numbers they would be assigned from lower to higher.

16

Oh, you're right, fixes: https://github.com/openwrt/packages/pull/20554 https://github.com/openwrt/packages/pull/20555

1 Like
18

Is that IPv4-only for requests or replies? Cause I'm getting ipv6 replies all the time:

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:4010:c0b::66
          2a00:1450:4010:c0b::8a
          2a00:1450:4010:c0b::64
          2a00:1450:4010:c0b::65
          74.125.205.102
          74.125.205.113
          74.125.205.101
          74.125.205.100
          74.125.205.139
          74.125.205.138

Is there an option to get only ipv4 replies?

19

Oh, the binary has been updated to handle -4 better probably.

Do you use the use_ipv6_resolvers_only setting in the config?

20

why am I getting this error for state.gov using https-dns-proxy

 nslookup state.gov
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:         ::1
Address:        ::1#53

** server can't find state.gov: SERVFAIL


dig state.gov

; <<>> DiG 9.18.10 <<>> state.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40142
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;state.gov.                     IN      A

;; Query time: 219 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu May 04 15:32:39 PKT 2023
;; MSG SIZE  rcvd: 38


[root@dca632 / 55°]# nslookup state.gov 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   state.gov
Address: 34.233.79.178
Name:   state.gov
Address: 2600:1f18:4659:1600:5c0e:d4cf:ce29:54c8

[root@dca632 / 55°]# nslookup state.gov 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   state.gov
Address: 34.233.79.178
Name:   state.gov
Address: 2600:1f18:4659:1600:5c0e:d4cf:ce29:54c8
21

No, I mean on the contrary, I don't want / don't care about ipv6 replies, but still getting them.
Where that use_ipv6_resolvers_only setting should go?
Tried adding to /etc/config/https-dns-proxy
option use_ipv6_resolvers_only '0'
option use_ipv4_resolvers_only '1'
but that didn't change anything.

And a second question regarding Encrypted Client Hello (and I'm not aware about the exact DNS requirements for it to work, but here is some info https://github.com/psf/requests/issues/5972), however if I enable DoH in the browser, it connects using ECH just fine (https://tls-ech.dev/ or https://defo.ie/ech-check.php), but using the OpenWrt DoH proxy it does not.

1 Like
22

By default, the PROCD script still starts the instances with the -4 parameter which (at least on my system) used to indicate we only want legacy addresses. How much have you disabled IPv6 on your system?

There's no such option.

I believe it has to be supported by the upstream: https://github.com/aarond10/https_dns_proxy, you may be better off asking there.

23

As I first replied in your other thread here let's keep the conversation there, but looks like you've already troubleshooted it to the point where dnssec is to blame.

1 Like