Add support for DNS over TLS (RFC 7858)

[hardfalcon]

Support for DNS over TLS (as specified in RFC 7858) would be nice:

https://tools.ietf.org/html/rfc7858

It's very simple to implement, you basically just put nginx as TLS frontend in front of the TCP port of the normal nameserver. Since RFC 7858 got assigned its own port 853, it won't interfere with normal operation. A quick configuration example can be found here:

https://dnsprivacy.org/wiki/display/DP/Using+a+TLS+proxy

The reference client implementation for RFC 7858 seems to be "stubby", which is built upon a library called "getdns". I'd recommend simply reusing getdns's default list of ciphersuites:

https://github.com/getdnsapi/getdns/blob/develop/src/context.c#L1426

Since release 1.3.0, getdns also supports TLS 1.3, however this requires OpenSSL 1.1.1, which is not released yet. To get support for TLS 1.3 on the server side, you'd equally have to build nginx using OpenSSL 1.1.1. Whilst some features of TLS 1.3 (0rtt) would obviously be nice to have, TLS 1.2 should be sufficient for the time being. TLS < 1.2 and/or non-PFS cipher suites should explicitly not be supported (stubby, which is by far to most widespread client implementation, does the same).

It seems that Google is currently working to include support for DNS over TLS into one of the next Android releases, so this will hopefully gain more momentum than DNScrypt did.

https://android-review.googlesource.com/q/topic:dns-dev-opt+(status:open+OR+status:merged)

[peterthomassen]

We're considering to implement DNS over HTTPS instead, as that seems to have a few advantages.

@hardfalcon , do you have any strong opinions on pros and cons?

The plan is to revisit this once dnsdist 1.4 is released (it comes with a few improvements in that area).

[hardfalcon]

First: I'm not opposed to DoH in any way - I'm actually running my own private DoH resolver in parallel to my DoT resolver, and I have started using the DoH resolver as the only DNS resolver on several machines I use every day, both on a Laptop and on Desktop computers (it's probably just an implementation or configuration issue, but when compared to DoT, DoH has far less issues with frequent network disconnects on my Laptop).

Of course, DoT and DoH can be run in parallel on the same server without interfering with each other - and my recommendation would be to just run both and look at the usage statistics.

However, with the current landscape of DoT and DoH implementations, DoH currently seems pretty useless to run on authoritative name servers (this may of course change in the future). Apart from manual debugging, authoritative name servers typically get queried by recursive resolvers like unbound, knot-resolver, PowerDNS or BIND in recursive mode. The problem is: none of these recursive resolver implementations seem to have a DoH client implementation (which they would need to make use of your DoH server), and none of those projects seem to be even just considering the possibility of adding such a DoH client implementation. Knot-resolver (and, as you mentioned, PowerDNS dns-dist 1.4) do only implement the server part of DoH, unbound and BIND implement none of both.

On the other hand, at least unbound has a DoT client implementation (along with a DoT server implementation), and can even be configured to only use (and require) DoT for certain zones while using traditional unencrypted DNS for the rest.

All the DoH client implementations that I'm aware of are only stub resolvers or DNS forwarders, so they probably won't be able to make actual use of your DoH server in any real-world usage scenario. The closest thing that I am aware of would be unbound's ability to download BIND zone files from a HTTPS server when run in authoritative mode - but that's of course a very different beast and can certainly not be considered an actual DoH client.

[peterthomassen]

Thanks for these insights! Does your argument about missing DoH support in resolvers also apply to DoT?

[peterthomassen]

https://arxiv.org/pdf/1907.08089.pdf may be interesting

[nils-wisiol]

Unfortunately the paper only covers the recurser. What we can learn though is that bare look-up times are slower with DoT and DoH in nearly all cases, but page load times may be faster using DoT. Cloudflare, Quad9 and Google all offer DoT and DoH. The paper also mentions censorship resistance as an advantage of DoH, as it uses port 443.

To conclude, I don't see a big advantage to offer DoT or DoH for our authoritative name servers currently. The benefits are marginal, and we have more important items on the agenda. If someone volunteers however, I'm happy to accept a contribution.