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

[nle]

Yes, thats what I saw. Hopefully someone else can confirm as well, because according to Cloudflares website they should support DNS over TLS.

But I'm pretty newbie in all this.

[elektroinside]

They do.. for 2 minutes

[RickNY]

Just an FYI -- Apparently there is an issue with 1.1.1.1 and Unbound that Cloudflare is aware of and will be resolved in their next update.. No ETA..
See attached
https://community.cloudflare.com/t/1-1-1-1-was-working-but-not-anymore/15136/4

[elektroinside]

Thanks for the report!

[unsound]

Looks like they have fixed the issue with Unbound already

https://community.cloudflare.com/t/1-1-1-1-was-working-but-not-anymore/15136/7

So far so good testing on my side.

[nle]

Just to be sure.

You specify the same DNS servers in the "General" settings, and then add this to the advanced section of Unbound?

[elektroinside]

For fallback cases, yes. If you delete these custom options (tls forwards) and re-enable forwarding mode, the DNS servers configured under "General" will be used.

[nle]

Thanks.

Only had it running for a few minutes, but it looks Cloudflare DNS (only) is working.

[RickNY]

Does seem to be working once again with TLS for me as well.. Also not receiving the "error: outgoing tcp: connect: Address already in use for 1.1.1.1" messages in the log (so far)

[tlund]

Great initiative. It would be amazing to have DNS-over-TLS support i Opnsense.

But just to be clear: the long term goal would be to support DNS-over-(TLS/HTTPS) on all links, that is
a) Client stub (desktop/laptop/smartphone) -> local forwarder (Opnsense)
b) local forwarder (Opnsense) -> resolver (external, eg 1.1.1.1/Quad9)
c) resolver -> authoritative nameservers

What we are focusing on right now is link b).
Link a) might be considered "private", since it's on our local subnet. But anyway, the configuration of any local clients can not be easily automated. (It must be done manually until a new DHCP-option is standardised some time in the future.)
Link c) we don't control (unless we run a resolver on Opnsense). Either way, the "resolver-to-auth" spec is still in early draft stage (1).

As for b):
Unfortunately, Unbound does not (yet) support authenticating the upstream TLS server (2).
Since the connection is not authenticated, it only protects against passive attackers (eavesdropping), not active on-path attackers (man-in-the-middle).
Unbound also does not support configuring the TLS client options(?) (specify supported versions, ciphersuites etc).
Stubby has partial support for this:

"Stubby supports TLS v1.2. In 'Strict' mode Stubby is limited to using the 4 Cipher Suites recommended in RFC7525, in Opportunistic mode is uses the default OpenSSL Cipher suites." (3)

One alternative listed by the dnsprivacy-project is to use Unbound+Stubby together (4):

Code: [Select]

local client -> unbound (caching proxy) -> stubby (running on same host as unbound) -> (DNS-over-TLS) -> external resolver (1.1.1.1/quad9 etc)
Stubby (aka getdns) can authenticate the upstream resolver, using the dnsName in the certificate, and by verifying that the certificate chains to a trust anchor (list of CAs) (5)

The dnsprivacy-project (6) is a great resource for understanding the challenges with DNS-privacy, and how DNS privacy is supported in various DNS software (10).

Just for reference, the relevant standards are:
"DNS-over-TLS" (7)
"Usage Profiles for DNS over TLS and DNS over DTLS" (8 )
 - just published (march 2018)
 - specifies 2 privacy profiles
   - strict (authenticate upstream server either via pubkey fingerprint, or by trust-chain+dns-name)
   - opportunistic (authentication of upstream server not required, basically what Unbound supports today)
"DNS-over-HTTPS" (9)
 - still in draft, but supported by both 1.1.1.1 and GoogleDNS

(1) https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01
(2) https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658
(3) https://dnsprivacy.org/wiki/display/DP/About+Stubby
(4) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients
(5) https://github.com/juzam/docker-getdns-stubby/blob/master/stubby.yml
(6) https://dnsprivacy.org
(7) https://tools.ietf.org/html/rfc7858
(8 ) https://tools.ietf.org/html/rfc8310
(9) https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-05
(10) https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status

And while we are discussing Cloudflare DNS, privacy and sharing logs with others:
https://community.cloudflare.com/t/privacy-policy-link/14890/4

[elektroinside]

Very nice summary, thank you!
Indeed, you're right. There's much to be done generally in order to get true security.
The only true security based on encryption is where you (to encrypt) and the decrypting party know the key. There is no other method. If you are not allowed to use your own key/password in any form and the decrypting party is not allowed to add that exact key to decrypt the communication, that's not true security.

For regular people, this is not an issue of course, most of the times.

Welcome to OPNsense!

[RickNY]

Does anyone else get occasional entries like below in their Unbound logs?

Code: [Select]

unbound: [49413:0] error: outgoing tcp: connect: Address already in use for 1.1.1.1

[opnfwb]

I also saw this error in the Unbound logs but, it has only happened one time on each of the addresses. I was wondering if it has something to do with CloudFlare's anycast address changing during a DNS request?

Code: [Select]

Apr 8 08:50:15 unbound: [53283:3] error: outgoing tcp: connect: Address already in use for 2606:4700:4700::1001
Apr 7 23:45:06 unbound: [53283:1] error: outgoing tcp: connect: Address already in use for 1.1.1.1

[acarlow]

Just thought I'd throw in that it's been working for me with Quad9 for a couple days with two different installations with no issues.

[crt333]

This seemed to work really nicely for a while, but after about 10 minutes unbound dies with:
  Apr 11 15:14:17   unbound: [87750:0] notice: ssl handshake failed 1.0.0.1 port 853
  Apr 11 15:14:17   unbound: [87750:0] error: ssl handshake failed crypto error:140020B5:SSL

Rebooted several times, result is always a dead unbound after a while

Logs did show requests going to port 853 though, this is really promising.