# DoH proxy: https-dns-proxy new RFC8484-supporting package and Web UI **URL:** \ **Category:** Community Builds, Projects & Packages\ **Created:** [December 20, 2019, 4:01am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832 "2019-12-20T04:01:01Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [December 20, 2019, 4:01am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/1 "2019-12-20T04:01:01Z")
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](https://github.com/openwrt/packages/blob/master/net/https-dns-proxy/files/README.md) ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [January 4, 2020, 4:22am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/2 "2020-01-04T04:22:02Z")
I would appreciate general proofing/feedback on the README: [https://github.com/stangri/openwrt\_packages/blob/master/https-dns-proxy/files/README.md](https://github.com/stangri/openwrt_packages/blob/master/https-dns-proxy/files/README.md). ---
**Author:** ![vbarter](https://forum.openwrt.org/letter_avatar/vbarter/32/5_5575768a8748004e209b776fc1b2916d.png) [@vbarter](https://forum.openwrt.org/u/vbarter)\ **Post date:** [January 5, 2020, 6:55am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/3 "2020-01-05T06:55:50Z")
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? ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [January 27, 2020, 11:55pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/4 "2020-01-27T23:55:01Z")
> [@vbarter](#): > > Edit: It was spotty at first but I ended up turning off Use DNS servers advertised by peer in WAN and WAN6 settings. This will be automatically disabled for affected DNSMASQ instances on start in the next version (2019-12-03-4). > [@vbarter](#): > > How can I add the IPV6 addresses for cloudflare as well? Please elaborate on your question. ---
**Author:** ![tapper](https://forum.openwrt.org/user_avatar/forum.openwrt.org/tapper/32/3012_2.png) [@tapper](https://forum.openwrt.org/u/tapper)\ **Post date:** [January 28, 2020, 7:52am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/5 "2020-01-28T07:52:06Z")
This app is very well dun. Thanks stangri BTW the LUCI app is grate with my screen reader too. ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 3, 2021, 2:32am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/6 "2021-05-03T02:32:43Z")
~~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`.](https://github.com/openwrt/packages/issues/15513)~~ ---
**Author:** ![rhester72](https://forum.openwrt.org/letter_avatar/rhester72/32/5_5575768a8748004e209b776fc1b2916d.png) [@rhester72](https://forum.openwrt.org/u/rhester72)\ **Post date:** [May 3, 2021, 2:41am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/7 "2021-05-03T02:41:52Z")
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? ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 3, 2021, 7:53pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/8 "2021-05-03T19:53:45Z")
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? ---
**Author:** ![rhester72](https://forum.openwrt.org/letter_avatar/rhester72/32/5_5575768a8748004e209b776fc1b2916d.png) [@rhester72](https://forum.openwrt.org/u/rhester72)\ **Post date:** [May 3, 2021, 9:08pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/9 "2021-05-03T21:08:10Z")
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) ``` ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 3, 2021, 10:16pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/10 "2021-05-03T22:16:15Z")
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`. ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [July 31, 2021, 10:22am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/11 "2021-07-31T10:22:46Z")
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! ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [October 15, 2021, 8:54pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/12 "2021-10-15T20:54:46Z")
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](https://github.com/stangri/source.openwrt.melmac.net/commit/67353c1db593354b3d62cb5631f0b4763c7a291a)). ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [February 22, 2023, 8:15pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/14 "2023-02-22T20:15:04Z")
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. ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [February 22, 2023, 8:41pm UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/16 "2023-02-22T20:41:59Z")
> [@anon11662642](#): > > By default, the ports are sorted in reverse order. Oh, you're right, fixes: [https://github.com/openwrt/packages/pull/20554](https://github.com/openwrt/packages/pull/20554) [https://github.com/openwrt/packages/pull/20555](https://github.com/openwrt/packages/pull/20555) ---
**Author:** ![yxtc934](https://forum.openwrt.org/letter_avatar/yxtc934/32/5_5575768a8748004e209b776fc1b2916d.png) [@yxtc934](https://forum.openwrt.org/u/yxtc934)\ **Post date:** [April 28, 2023, 12:12am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/18 "2023-04-28T00:12:43Z")
> [@Policy-Based-Routing (pbr) package discussion](https://forum.openwrt.org/t/policy-based-routing-pbr-package-discussion/140639/425): > > https-dns-proxy starts instances with `-4` parameter for IPv4-only mode Is that IPv4-only for requests or replies? Cause I'm getting ipv6 replies all the time: ```plaintext 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? ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 1, 2023, 1:45am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/19 "2023-05-01T01:45:55Z")
> [@yxtc934](#): > > Is there an option to get only ipv4 replies? Oh, the binary has been updated to handle `-4` better probably. Do you use the `use_ipv6_resolvers_only` setting in the config? ---
**Author:** ![neil1](https://forum.openwrt.org/letter_avatar/neil1/32/5_5575768a8748004e209b776fc1b2916d.png) [@neil1](https://forum.openwrt.org/u/neil1)\ **Post date:** [May 4, 2023, 10:44am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/20 "2023-05-04T10:44:46Z")
why am I getting this error for [state.gov](http://state.gov) using `https-dns-proxy` ```plaintext 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 ``` ```plaintext 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 ``` ```plaintext [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 ``` ---
**Author:** ![yxtc934](https://forum.openwrt.org/letter_avatar/yxtc934/32/5_5575768a8748004e209b776fc1b2916d.png) [@yxtc934](https://forum.openwrt.org/u/yxtc934)\ **Post date:** [May 5, 2023, 12:08am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/21 "2023-05-05T00:08:19Z")
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](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/](https://tls-ech.dev/) or [https://defo.ie/ech-check.php](https://defo.ie/ech-check.php)), but using the OpenWrt DoH proxy it does not. ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 7, 2023, 2:40am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/22 "2023-05-07T02:40:51Z")
> [@yxtc934](#): > > No, I mean on the contrary, I don't want / don't care about ipv6 replies, but still getting them. 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? > [@yxtc934](#): > > `option use_ipv4_resolvers_only '1'` There's no such option. > [@yxtc934](#): > > And a second question regarding **Encrypted Client Hello** I believe it has to be supported by the upstream: [https://github.com/aarond10/https\_dns\_proxy](https://github.com/aarond10/https_dns_proxy), you may be better off asking there. ---
**Author:** ![stangri](https://forum.openwrt.org/user_avatar/forum.openwrt.org/stangri/32/58_2.png) [@stangri](https://forum.openwrt.org/u/stangri)\ **Post date:** [May 8, 2023, 2:18am UTC](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832/23 "2023-05-08T02:18:33Z")
> [@neil1](#): > > why am I getting this error for [state.gov](http://state.gov) using `https-dns-proxy` As I first replied in your other thread [here](https://forum.openwrt.org/t/dnsmasq-https-dns-proxy-servfail-error-problem-resolving-state-gov/159306/) let's keep the conversation there, but looks like you've already troubleshooted it to the point where `dnssec` is to blame. [Next page](https://forum.openwrt.org/t/doh-proxy-https-dns-proxy-new-rfc8484-supporting-package-and-web-ui/50832.md?page=2)