unbound: DNS over HTTPS (DoH) Support (requires unbound to be made with libnghttp2)

[raymondmack]

Maintainer: @EricLuehrsen

Description: Unbound has supported DoH since the 14th of Dec. 2020:

https://blog.apnic.net/2020/12/14/dns-over-https-in-unbound

https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-https.html

Openwrt's unbound package currently has support for DoT forwarding, while DoH support has yet to be implemented. The links above cover how to implement DoH with Unbound, but will require OpenSSL v1.0.2 or newer and the unbound package to be made with the nghttp2 library (libnghttp2).

I've opened another request with the luci-app-unbound package to implement the LuCI interface for this feature under Zones: #6931

Here are the instructions given in the article for reference:

The DoH implementation in Unbound requires TLS, and only works over HTTP/2. The query pipelining and out-of-order processing functionality that is provided by HTTP/2 streams is needed to be able to provide performance that is on par with DoT. The HTTP/2 capability is negotiated using Application-Layer Protocol Negotiation (ALPN) TLS extension, which is supported in OpenSSL from version 1.0.2 onward.

We decided to use the amazing nghttp2 library to handle the HTTP/2 framing layer. This library does not take care of any I/O handling, which makes it possible to easily integrate it in the existing Unbound event loop and TCP handling. Adding HTTP/2 on top of the existing TCP code makes it possible to also use the existing TCP configuration options for the DoH connections. These existing options include the number of allowed incoming TCP connections, the TCP timeout settings, and the limits on TCP connections per client IP address or netblock.

Using DoH in Unbound

As mentioned above, the nghttp2 library is required to use Unbound’s DoH functionality. Compiling and installing Unbound with libnghttp2 can be done using:

./configure --with-libnghttp2
make && make install

Enabling DoH in Unbound is as simple as configuring the TLS certificate and the corresponding private key that will be used for the connection, and configuring Unbound to listen on the HTTPS port:

server:
   interface: 127.0.0.1@443
   tls-service-key "key.pem"
   tls-service-pem: "cert.pem"

The port that Unbound will use for incoming DoH traffic is, by default, set to 443 and can be changed using the https-port configuration option.

[BKPepe]

@EricLuehrsen is our Unbound maintainer

[BKPepe]

In any case, you need to enable it here: https://github.com/openwrt/packages/blob/2953350f7561ec0e2725f532a10dbc2c2a95759a/net/unbound/Makefile#L148

Then compile the unbound yourself, copy it to the router and install it.

[brada4]

First you need to justify building DoH configuration of unbound (bigger than default) alongside default one, likely in forums. That article is unfounded - no chance DoH goes along with QNAME minimisation.

[dibdot]

This has already been answered by the maintainer: https://github.com/openwrt/packages/issues/22845#issuecomment-1848273825

[vincejv]

This has already been answered by the maintainer: #22845 (comment)

DOH serving is not typical for a hobby use of OpenWrt.

That's a separate issue, the issue you referred to refers to Unbound as a DoH server, this issue however refers to Unbound being as a DoH client, but feel free to correct me @raymondmack , edit: the apnic quote you mentioned refers to DoH client AND server, however the luci issue you opened seems to refer being to unbound as a DoH client.

If you are on a docker supported platform, there are plenty of docker images available for unbound. 27mb for libnghttp2 enabled

[brada4]

DoH is last mile protocol. Nice to have client in the server, but standards absent it needs peer agreement for each and every zone defeating the purpose of DNS.

[vincejv]

DoH is last mile protocol.

The point of DoH was to battle censorship, like government blocking random websites.

DoT can be blocked due to having a standard port - 853 tcp, I haven't heard of a public DoT provider using a non-standard port, or even an OS that support not using a non-standard port. Android as an example doesn't support changing the port for DoT.

On the other hand, Do53 (Regular DNS UDP port 53) can be trivially intercepted and easy to MITM a.k.a. ISP's DNS transparent proxy.

[brada4]

You can put censored domains selectively to doh/dot/dnscrypt proxy running locally, without claiming it is general usage scenario to cover.

[vincejv]

That's just silly and micromanagement of a network, if you're referring to censored domains, they change from time to time due to censorship. Plus you have to take account of the subdomains and aliases.

If this is what OpenWRT devs think and refuse to fix it, there are multiple options this can be worked around without their intervention.

• Compile a custom IPK with those flags enabled
• Build a static unbound https://github.com/NLnetLabs/unbound/issues/91 and upload the compiled binaries to your OpenWRT.
• Docker as mentioned in previous comment
• Use AdguardHome instead

[brada4]

Yes, the IPK with flags can be compiled. Thats it. Nothing is refused. If you have big device that can run adguard you can run beefed-up unbound. Wont help 8mb flash 64mb ram stay out of landfill.

[EricLuehrsen]

Consider that we want to promote entry level experimentation and show a benefit over OEM firmware (often enough abandoned early or poorly maintained). The packaging for releases needs to be reasonable and reliable. Adding to Unbound is challenging in two parts: (1) it starts growing too big for general use on fixed size firmware devices, or it drags along libraries to that effect. (2) Unbound needs a matched pair compiled libunbound, and mixed compile-option packaging has not been so reliable.

DOH is for those that think the entire internet is only HTTPS (joking). Really though, DOH gives browsers a direct way to bypass infrastructure and avoid malicious actors. Single middle-hop DOH will not satisfy that requirement.

[raymondmack]

however the luci issue you opened seems to refer being to unbound as a DoH client

@vincejv, correct. I should have mentioned that I was only asking for DoH client support (forwarding DoH requests not serving them). The current LuCI interface for unbound provides DoT forwarding support and I thought it odd that DoH wasn't included. But I can see now that this issue is more complicated than I anticipated. Though, from my layman's perspective, I don't see what harm can come from providing a separate unbound package made with libnghttp2 so less technically inclined individuals can enable DoH forwarding by downloading the appropriate package from the openwrt repo.

[brada4]

Yeah, after noob-bashing intro now you poor laymans.

[vincejv]

@raymondmack it seems like we've heard from the maintainer and it's obvious he won't add DoH as they don't understand DNS Censorship as they are probably living in a country with little to no censorship, it is the most common way of blocking websites by the government and ISP.

~Use this OpenWRT fork instead (another option), https://github.com/coolsnowwolf/lede meant to be used in countries like China which has a lot of censorship and government interception.~

~It has DoH enabled as based on the Makefile, it has libnghttp2: https://github.com/coolsnowwolf/packages/blob/142bd254b83390a7e1b79b146b851fa9feba9410/net/unbound/Makefile#L31~ Just follow BKPepe's advise and compile the ipk yourself.

Also to answer your question why not maintain a separate package (unbound-mini and unbound-full just like how dnsmasq is), I've used OpenWRT long enough to memorize the usual and typical reasons why most feature requests are denied that why coolsnwwolf created the fork, it may fall under these categories

1. Maintenance overhead on the development side
2. Buildbot getting overworked due to compiling multiple packages (adding 1 package is apparently a huge thing since you're compiling against multiple targets, architectures and devices)
3. Server storage cost on hosting the additional ipk packages (since multiple targets as mentioned on no. 2)

IMO i consider this issue as "won't fix".

[BKPepe]

Woah, what happened with this issue. What a discussion here. So many comments from different users. That's interesting. If we are talking about maintenance overhead. Let me bring the discussion even elsewhere with 🍿 , who of you reviewed at least one pull request here or even submitted PR?

Feel free to submit PR with DoH support, feel free to use different DNS resolver, feel free to compile it yourself (and that's what Turris are doing) and feel free to cooperate with upstream, but splitting unbound-mini/full is not a solution. Right now, you do have 7 unbound packages including library. You dont need to use it all, but do you want to have so many packages, who will test it? 🤔

[vincejv]

Let me bring the discussion even elsewhere with 🍿 , who of you reviewed at least one pull request here or even submitted PR?

You don't directly submit a PR when in the past the project has been known to snub Feature Requests PRs due to lack of interest from the maintainers to even review or look at the PR. It's a waste of time and effort really from the contributor and reviewers, that is why it is important to discuss the feature request first before submitting any PR, that is the purpose of the issue tab in Github to discuss and deliberate the general consensus on a feature request.

If it's a bug fix then yes, you are correct you can directly open a PR for review, but for feature request it's definitely important to discuss it first, but maybe in OpenWRT Forums first before a Github issue.

[EricLuehrsen]

The challenges lie in both Unbound and Opkg. Unbound needs its libunbound and libunbound is used by a few other OpenWrt packages. Opkg is powerful for its foot print but it has limits. I have created dependency entanglements once already that needed reversion. Splitting the package again doesn't seem feasible. Unbound is the kind of application that is not dynamic with third party libraries. It cannot detect missing library, so disable a singular feature. Once compiled it needs that library and any next dependent library, or it won't load. So its a balance. What package of Unbound is appropriate as the OpenWrt package? What level of features should be on a more substantial infrastructure appliance?