***call for testing*** DNS TLS encryption using Quad9 and Cloudflare DNS servers

[opnfwb]

Call out for testing DNS over TLS with the new Quad9 and Cloudflare DNS servers that have been discussed recently. I wanted to see if we could get the default Unbound instance in OPNsense to use these new DNS encrypted and privacy oriented DNS providers.

I'm currently using these and this appears to be working because I can see all of the outbound queries in the pfTop view on OPNsense. I see outbound DNS queries on port 853 going to the addresses that I have specified in the custom options. Internal LAN queries come in over port 53 as per usual but outbound queries to the WAN now happen on Port 853 to the DNS TLS providers listed below.

Here are the settings I have configured to get Unbound to send DNS over TLS to Quad9 and Cloudflare.

OPNsense x86_64 18.1.5
UnboundDNS/General

Code Select Expand

Enable DNS resolver (checked)

Code Select Expand

Enable DNSSEC support (checked)

Code Select Expand

Enable Forwarding mode (UNCHECKED, had to do this to get these to work)

Paste these values in to the custom options field. Save/Apply settings.
Custom Options:

Code Select Expand

ssl-upstream: yes
forward-zone:
name: "."
forward-addr: 9.9.9.9@853 #Quad9 ip4
forward-addr: 149.112.112.112@853 #Quad9 ip4
forward-addr: 2620:fe::fe@853 #Quad9 ip6
forward-addr: 1.1.1.1@853 #Cloudflare ip4
forward-addr: 1.0.0.1@853 #Cloudflare ip4
forward-addr: 2606:4700:4700::1111@853 #Cloudflare ip6
forward-addr: 2606:4700:4700::1001@853 #Cloudflare ip6

You should now have DNS queries going to Port 853 using TLS to the addresses specified in the custom options field. Obviously, if you aren't using ipv6, you can omit some of the addresses. If you only want to use Quad9 or Cloudflare, you can omit whichever provider you don't want to use.
I'd love to have other folks try this out and report their findings.

As far as I can tell this seems to be working very well and it was quite easy to configure. However, I don't consider myself an "advanced" user and I would like to see feedback from others here just to ensure that this is a good setup to use going forward.

[elektroinside]

Works perfectly fine here (so far).
Well done!

Although I would need to see those packets over a dump, to check if these are really going over TLS.

[franco]

There is one Twitter thread here with an error report... https://twitter.com/colinsmall/status/981348043080585216

But it might be the ISP getting in the way.


Cheers,
Franco

[elektroinside]

No such thing here... Still working fine :)

[franco]

I've seen the no cipher warning recently... it was due to a PAN firewall playing with fire in SSL proxy / peek mode, but failing to know a couple of ciphers that LibreSSL could do. ;)

[Evil_Sense]

Tried it, sadly unbound stops working aftter some minutes, stating "SSL_handshake syscall: Connection reset by peer"

I'm using only the Quad9 address and LibreSSL.

[franco]

Just for fun, try OpenSSL.

[Evil_Sense]

Just for fun, try OpenSSL.

Same thing, resolver.log shows no error

[elektroinside]

I'm also using Quad9 with LibreSSL. Still working fine :)

[Evil_Sense]

My bad, unbound wasn't starting because of an include, seems to work so far..
I'll retry with LibreSSL.

Is there a log file other than resolver.log?

Edit:

Unbound dies with both OpenSSL and LibreSSL after approximately 2 minutes with a handshake failure "no ciphers available; ssl handshake failed 9.9.9.9 port 853".

With LibreSSL I also see:
"error: could not SSL_new crypto error: 14FFF0E4:SSL routines:(UNKNOWN)SSL_internal:ssl ctx has no default ssl version"

[franco]

It still looks like someone is meddling with your (DNS) SSL stream. :(

[Evil_Sense]

Well OPNsense is running behind an ISP router, but I don't think this is the issue, since I never had any problems with this setup..

There is no proxy or interception running on OPNsense or elsewhere.

[elektroinside]

This is also how some MITM attacks/behaviors look like.
Not saying that your ISP does something similar, but something/somebody is interfering with it. Maybe a service running on that same port?

[miroco]

There is an updated version of unbound available - 1.7.0

Amongst the features:

"Accept tls-upstream in unbound.conf, the ssl-upstream keyword is also recognized and means the same. Also for tls-port, tls-service-key, tls-service-pem, stub-tls-upstream and forward-tls-upstream."

http://www.unbound.net/download.html

[Evil_Sense]

This is also how some MITM attacks/behaviors look like.
Not saying that your ISP does something similar, but something/somebody is interfering with it. Maybe a service running on that same port?

Every other TLS connection works fine and has the expected certificate, a test with openssl s_client to 9.9.9.9:853 succeeded..