Unbound needs certificate picker to serve DoT/DoH

[FireStormOOO]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [*] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [*] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
While Unbound supports serving DNS over TLS and DNS over HTTPS requests from clients, this requires setting a certificate for Unbound to use, and the web GUI is not exposing a certificate picker currently. This is the last missing feature for feature parity with pfsense's unbound wrapper. Note that this is distinct from the resolving behavior; this is unbound listening on 853 for clients using DNS over TLS.

Describe the solution you like

The Services > Unbound > General tab should provide a certificate picker that wires up a system certificate to unbound's tls-service-key and tls-service-pem options

Describe alternatives you considered

N/A; there's kinda just the one obvious implementation. I guess it could go on the Advanced tab instead.

Additional context

The equivalent setting on the pfsense side:

[fichtner]

Just add the CA to System: Trust: Authorities. Self signed is also accepted there.

[FireStormOOO]

Unbound resolving over TLS is working fine. I'm talking about having Unbound listen on 853 to clients using DNS over TLS

[fichtner]

We don’t support this. It has been discussed a while back.

Cheers,
Franco

[FireStormOOO]

#5104
#6558

Those are making this far more complicated than it needs to be. DoT just needs the cert provided AFAICT, and that seems to be the consensus in the above as well. Nothing else is trying to bind 853. I understand not wanting to deal with DoH since 443 is taken, and DoT is the better standard anyways.

I was mistaken with regards to what PFSense has - they went for only implementing DoT.

The use case is the same opportunistic encryption that DoT is for in the first place - yes, it requires client configuration to trust the specific DNS server for the network, but that's hardly a large ask in a managed environment. Failing that it's the same security profile as self-signed certs, better vanilla DNS, but only against passive eavesdropping.

DoH would be straightforward if it just had a requirement that it couldn't bind the same interface as web management. Alternately, it looks like it only needs the one /dns-query path, which could conceivably coexist with web management if they're using the same cert.

Is there any appetite for revisiting just DoT?

[maurice-w]

@FireStormOOO You can do this with a simple custom include:

server:
  interface: 2001:db8:1234:53::1@853
  interface: 2001:db8:1234:53::1@443
  interface: 192.0.2.53@853
  interface: 192.0.2.53@443
  tls-service-key: "/var/etc/acme-client/keys/[...]/private.key"
  tls-service-pem: "/var/etc/acme-client/certs/[...]/fullchain.pem"

To avoid any conflicts with port 443, using an additional loopback interface is recommended. I've been running such a config for several years without any significant issues.

[gregtwallace]

To avoid any conflicts with port 443, using an additional loopback interface is recommended. I've been running such a config for several years without any significant issues.

Can you elaborate on the additional loopback interface setup? I was going to setup just DoT with a custom include but adding DoH as well if it isn't a pain would be nice. Thanks!

[maurice-w]

'System: Settings: Administration', select the listen interface(s) which have the IP addresses you use for accessing the web GUI.
'Interfaces: Devices: Loopback', add an interface, assign it and configure static IP addresses.
In the Unbound settings, select this loopback interface. In the custom include, use the IP addresses of this loopback interface.
Configure these IP addresses as the DNS server in the DHCP and Router Advertisement settings.

Can also be done in the opposite way: Use a loopback interface for the web GUI and "real" interfaces for Unbound.