Unbound for DoH

[CallMeR]

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

Describe the solution you like
https://blog.nlnetlabs.nl/dns-over-https-in-unbound/
I've noticed that Unbound could be configured to support DoH.
Will WEB UI support this feature someday？

[fichtner]

In practice it is quite difficult to make port 443 the DoH port for a LAN segment, but in principle I agree that it should be added to the GUI.

I will work on it after 21.7 is released.

Cheers,
Franco

[CallMeR]

Thanks for your reply :)
I agree that it is very difficult to listen to DNS requests on port 443, but few devices can natively use DoH or DoT for DNS queries.
Therefore, if you can forward to the DoH port (443) like forwarding ordinary DNS (port 53) to DoT (port 853), and then configure the DoH server on the external network, it is enough for now.
Just like ：

Configure a DoH, it seems that only a domain name is needed，like https://somedomin/dns-query?

[CallMeR]

By the way, I am very much looking forward to the release of the new version 21.7, and I am going to reinstall my OPNsense :)

[fichtner]

I'm not sure I understand because actually the DoH seems to be a server, not a client like DoT seen here. You basically need a virtual IP for that and/or a port forward. I suppose we need to support tls-port: and https-port: directives along with it.

And, yes, from the looks of it 21.7 will be pretty good. We are excited for the release at least anyway. :)

Cheers,
Franco

[fichtner]

Note to self:

server:
   tls-port:              dotport
   https-port:         dohport
   tls-service-key "key.pem"
   tls-service-pem: "cert.pem"

tls-service nodes should be enabled per "DoH-DoT server" setting enable/disable or just use the certificate selector.

[fichtner]

Via https://twitter.com/DKaufmann_/status/1421023327762751489

[swhite2]

I'm not entirely sure how useful this is considering:

1. Unbound is as of yet not capable of forwarding DNS-over-HTTPS queries. As far as I can tell it's only capable of responding to queries locally on /dns-query. The queries are encrypted only locally, and every single client needs to configure this separately for every application that is to use DoH. These queries can then be forwarded either in plain-text or DoT. But considering we'd have to use a nondefault port or complicate the setup with VIPs and port forwards 'automagically' seems brittle to me.
2. The only way for Unbound to forward DoH queries is if the client on the initial connection explicitly disables TLS and Unbound is configured with the http-notls-downstream option meant for backend servers. This is not possible in most client applications that use DoH such as Firefox.
3. DNS-over-TLS outshines DoH in terms of performance.
4. There is no real way to stop clients from using DoH by specifying their own nameservers (let's say 8.8.8.8, should it support DoH). Unbound cannot act as a man-in-the-middle for it as DoH was designed to prevent that from happening.

This all considers DoH as a forwarding mechanism. Should people really wish to use DoH locally we could consider supporting it with a nondefault port, as it requires client configuration anyway.

[schreibubi]

Let me respond to your concerns:

1. Correct DoH will only encrypt the connection between the client and OPNsense, then it depends on the OPNsense Unbound configuration on how the lookup is getting handled. I'm not too concerned about about the port usage itself, just move the Web-GUI to a different port, then the standard https port can get used for DoH. In my setup the Web-GUI is only reachable on the Management Interface, while Unbound listens on port 443 on the LAN interface
2. You can encrypt DoH traffic in your LAN: I'm resolving dns.abc.com to the LAN interface IP and have obtained a Let's encrypt certificate for that hostname. Firefox works then nicely with the following DoH URL: https://dns.abc.com/dns-query
3. Can't comment on that
4. I'm currently blocking all https accesses to the list of known DoH servers in the firewall using this list https://github.com/jpgpi250/piholemanual/blob/master/DOHipv4.txt and the corresponding list for IPv6.

DoT is much nicer in quite a few aspects, especially that Android phones first try to use DoT on port 853 for the router address they obtain through DHCP. So DoT gets used automatically, while DoH always needs explicit configuration.

I'm the author of PR #5468, so please take a look if any changes to that PR are required.

[swhite2]

If client-side encryption is the wish, and there are no interactions between transport configurations on the incoming side (query) vs outgoing side (recursion) which might cause problems, it might make sense to include both client-side DoH and DoT.

However, the current PR implements it in legacy code, even though there is a DoT section in MVC code available. Granted, this section only applies DoT via forwarding, so in my opinion this would have to be rewritten to clearly represent the different options available, and clearly distinguished between traffic direction.

In all cases though for the client, this would require either manual configuration or effort to obtain a certificate, which is not part of the workflow of the core product, as such we cannot default to anything easily which will eventually cause more confusion than provide a solid solution. I'll put it up for discussion internally.

[CallMeR]

It should be that I didn't describe the request clearly initially.
My initial thought was that I wanted OPNsense to be able to use DoH to send DNS requests to upstream DNS servers for encrypted DNS traffic. Because OPNsense already works with DoT.

Just like:

[swhite2]

@CallMeR Forwarding over HTTPS isn't supported by Unbound, while DoT is.

DoH is still a valid feature request for OPNsense, but only for client-side configuration. Therefore the issue diverged to that discussion because DoT can also be supported client-side.

[AdSchellevis]

After lengthy discussions we decided we are not going to integrate this in the foreseeable future as we do seem to have issues explain its use, see also #6558 (comment)