search

openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
4.01k stars 3.49k forks source link

[unbound] update to source release 1.12.0 #13623

Closed ghost closed 4 years ago

ghost commented 4 years ago

Maintainer: @EricLuehrsen

Description: source release version 1.12.0 https://github.com/NLnetLabs/unbound/releases/tag/release-1.12.0 introduces DoH for downstream clients. It would be appreciated for the package to be updated.

EricLuehrsen commented 4 years ago

I am aware. Without certificate issuing standard for OpenWrt intranet resources DOT or DOH downstream is hard to make good use of. If you already control all the devices and can install a ad-hoc certificate, then also the network is closed off, so DOT or DOH are of little value downstream. See also discussion on LuCI certificates (http://lists.openwrt.org/pipermail/openwrt-devel/2020-October/031634.html) Anyway I am more concerned about a new feature creating problems like stuck resource (https://lists.nlnetlabs.nl/pipermail/unbound-users/2020-September/006971.html) or memory leak (https://github.com/NLnetLabs/unbound/issues/318). It would be more interesting if 1.12.0 solved some bugs we've seen in OpenWrt.

ghost commented 4 years ago

If you already control all the devices and can install a ad-hoc certificate, then also the network is closed off, so DOT or DOH are of little value downstream

The certificate generation and respective downstream distribution is not an issue for me, but that either clients' OSs and/or applications leveraging Do..T | H over dport(s) 443 | 853. With unbound's IP_TRANSPARENT socket option and nftable's tproxy statement thus I am able to prevent downstream clients trying to bypass the router's resolver instance for ports 53 & protocol TLS dports 443 | 853.

It would be handy if DoH can be filtered similarly.

Anyway I am more concerned about a new feature creating problems like stuck resource (https://lists.nlnetlabs.nl/pipermail/unbound-users/2020-September/006971.html)

I am not sure to which extent the observed behaviour is related to a new unbound feature or even if it is a bug in unbound or some particular implementation of OpenWrt, either the kernel or the app. From the ML it does not look like that the unbound developers picked up on it.

or memory leak (NLnetLabs/unbound#318).

Does not reproduce on my OpenWrt node, does it on yours? On my node unbound is listening on four ipv4 addresses and four ipv6 addresses respectively, each incl. localhost. Though the RPZ being fetched are as less in size, max. 27 MB, and some are fetched via HTTPS instead of axfr.

EricLuehrsen commented 4 years ago

When Unbound added DoT, it generated memory leaks and crashes by using OpenSSL libraries incorrectly. As much as DoH is interesting, as a package maintainer I don't want to be caught in the first wave of those. Even when compile-option off (I'd expect that for default), the structure in Unbound has changed.