
DNS over TLS – Thoughts and Implementation - kedmi
https://sagi.io/2018/09/dns-over-tls---thoughts-and-implementation/index.html
======
nykolasz
Pretty much there are 3 competing implementations for DNS resolution
encryption (won't call it security):

    
    
      * DNSCrypt
      * DNS over TLS
      * DNS over HTTPS
    

If you are looking for something well tested and well supported, check out
DNSCrypt (and the awesome DNSCrypt-proxy):

[https://github.com/jedisct1/dnscrypt-
proxy](https://github.com/jedisct1/dnscrypt-proxy)

It doesn't get a much love as it should, but it is probably the best way to
secure encrypt your DNS requests right now. The protocol was initially
developed by OpenDNS, but many resolvers support it right now (cisco,
cleanbrowsing, etc). The list of supporting services is impressive:

[https://download.dnscrypt.info/dnscrypt-
resolvers/v2/public-...](https://download.dnscrypt.info/dnscrypt-
resolvers/v2/public-resolvers.md)

On the other hand, DNS over [HTTPS|TLS] are pretty new and don't have as much
support, except for a few players. A good list if here as well:

[https://www.reddit.com/r/sysadmin/comments/976aj2/updated_li...](https://www.reddit.com/r/sysadmin/comments/976aj2/updated_list_of_public_dns_resolvers_curated_by/)

------
dagenix
Prediction: DNS-over-TLS won't win. I don't think it's going to be able to get
around the non-standard port issue.

Instead, I think DNS-over-HTTP is gonna be the champ. The overhead of HTTP is
a minor issue, but, I think using a standard port more than makes up for it. I
think the real inflection point is going to be once QUIC is more widely
deployed. Combined with TLS's 0-RTT connection setup, we'll be able to get
back to answering a DNS query in a single round trip (like today), but with
assurances that the data wasn't monitored or tampered with between the client
and the recursive resolver.

~~~
nykolasz
I hope you are wrong. We don't need one more protocol tunneled through HTTP.

~~~
dagenix
Why? What's the specific harm? AIUI, as long as the request still fits into a
single frame, its not anymore inneficient.

~~~
nykolasz
First, I think it gives too much power to the browsers. Firefox was already
taking some dangerous choices with DNS over HTTPS on some of their recent
changes. Chrome as well, doing changes that will benefit Google, in detriment
of the rest of the web.

Second, I think it is an overall bad design choice to tunnel a lightweight
protocol on top of HTTP on top of TLS. Instead of just tunneling it under TLS.

~~~
jrockway
I don't really see how encoding a DNS request as HTTP gives extra power to
browsers. What power do they gain by writing "GET www.example.com" after a TLS
handshake with port 443 versus writing "1234 0 0 0 0 1 0 0 1 0 0 0 ..." after
a handshake with port 53?

Browsers can already do whatever they want to the URL you type in. What DNS
packets look like does not add or remove any power.

Meanwhile, https isn't exactly heavy, and it's very well supported by
everything. Every programming language has an https library. Writing an DNS-
over-HTTPS program will be 3 lines of code.

------
fanf2
I deployed DNS-over-TLS on Cambridge University’s central recursive DNS
servers last week, and they immediately started receiving traffic from Android
P users - not very much traffic, a few queries per second, but not negligible.
I did some followup investigation of how Android behaves in the wild and
posted them to the IETF DoH list (and the dprive list but for some reason
those copies did not go through) - see
[https://mailarchive.ietf.org/arch/msg/doh/I-ytiO6ykbt9krrC9F...](https://mailarchive.ietf.org/arch/msg/doh/I-ytiO6ykbt9krrC9FVGEFo-
CA4) and the corrections and further information in the replies.

I still need to verify that TCP fast open is working, to minimize the DoT
latency.

~~~
amaccuish
Is there a new dhcp option to indicate availability, or is it opportunistic,
when the device notices port 853 is open?

~~~
fanf2
Android 9 Pie is opportunistic: it tries to connect to port 853 and sends a
probe query to make sure the server behaves plausibly well. Other clients need
explicit configuration.

------
tssva
Article starts by stating that DNS doesn't provide a means to guarantee
integrity of the returned DNS data.

Then mentions DNSSEC as a protocol which exists to provide such guarantee and
promptly dismisses it along with DNSCURVE and DNSCRYPT as protocols which have
been so infrequently deployed as to be non-existent.

Further on states that DNS over TLS and DNS over HTTPS don't solve the
integrity problem but that is ok because DNSSEC will provide that.

My head is spinning.

~~~
tptacek
There's two ways to ensure the authenticity of data delivered over the
Internet. You can authenticate the _content_ or you can authenticate the
_channel_.

Overwhelmingly, practical security schemes on the Internet rely on _channel
security_. We rely on TLS to ensure the integrity of the DOM on websites; we
don't cryptographically sign the pages themselves.

All things being equal, you'd like to be doing _both things_. You'd like to
have cryptographically signed web page DOMs, for instance (among other things,
it would make web crypto a lot more useful).

But all things aren't equal: content authentication is difficult to manage in
practice, and every security protocol we adopt has a cost.

Long story short: if you can protect the channels used by DNS lookups, you can
get by without protecting the content. That's roughly the idea behind DoH and
DoTLS.

The reality though is that all you really need is "DNS over TCP" (which, of
course, we've had since basically the beginning). Practical forgery attacks
against TCP DNS are difficult enough as to not be worth the trouble.

~~~
seabee
Practical forgery attacks against an arbitrary client are hard, but
configuring a public WiFi AP to intercept your favourite repeating-digit DNS
server is trivial. Lots of people use public WiFi!

In such a scenario a VPN is a more secure answer than DNS-over-TLS, but this
isn’t a realistic answer for the average user. It has to be something that is
free and easy to enable.

------
auslander
I recently configured my OPNsense router, for DNS over TLS with Quad9, with
certificate domain validation. It uses included Unbound resolver. Not sure
what I achieved, but it does feel good :)

[https://forum.opnsense.org/index.php?topic=9197.msg41265#msg...](https://forum.opnsense.org/index.php?topic=9197.msg41265#msg41265)

~~~
Fnoord
I've done the very same thing, on an EdgeRouter Lite [1].

Quad9 also supports DNSSEC.

[1] [https://www.chameth.com/2017/12/17/dns-over-tls-on-
edgeroute...](https://www.chameth.com/2017/12/17/dns-over-tls-on-edgerouter-
lite/)

~~~
js2
Switching to unbound seems like extra work. I kept dnsmasq on my EdgeRouter
and just pointed it at doh-client from [0] which is trivial to cross-compile.
I’m using Google’s dns servers as upstream.

[0] [https://github.com/m13253/dns-over-https/tree/master/doh-
cli...](https://github.com/m13253/dns-over-https/tree/master/doh-client)

~~~
Fnoord
Thanks for mentioning an alternative.

It is extra work either way. What is better performance though?

I'm using dnsmasq with Pi-Hole's blocklists, and forwarding to unbound for DNS
over TLS. Forwarding to another client such as doh-client could also work
though I'm not sure how this would work with Quad9.

My router is being backup for this ensure there's less load on the MIPS
machine.

Go is cross-platform, sure. However dnscrypt-proxy [1] is also very portable.

[1] [https://github.com/jedisct1/dnscrypt-
proxy](https://github.com/jedisct1/dnscrypt-proxy)

~~~
js2
I’m not sure about better performance. Once it’s cached it doesn’t matter.

Using unbound won’t survive an EdgeOS upgrade will it? Maybe a script under
/config/scripts could ensure unbound is installed and configured though.

------
auslander
Project dnsprivacy-monitoring, auto updated table of supported security
features by DNS provider:

[https://dnsprivacy.org/jenkins/job/dnsprivacy-
monitoring/](https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/)

------
bogomipz
I used Stubby and Quad9 for a few months last year but I found the latency
pretty terrible unfortunately. I would be curious to hear what other people
are using and what their experience has been.

~~~
ggm
I used SSH SOCKS tunnels with stubby to keep myself online inside China's
state firewall two recent trips. commercial VPN are routinely slowed down or
blocked, if you have the luxury of an SSH enabled host "outside" you can use,
Stubby and this are good, to get around DNS rewriting tricks and port/ip
filters.

Yes, you have have slower paths, trombone paths. But in the circumstances I
was in, Stubby was a godsend.

Also check out the dns security option in Android Pie.

~~~
bogomipz
Interesting. Can I ask what you used for your SSH host so that latency was
bearable?

~~~
ggm
A node in Brisbane. I checked path, the AS path was pretty tight, china-
telecom to telstra-reach and then into the IX where I have a FreeBSD host. I
was testing web speeds to the company on non-SSH/SOCKS paths, they were pretty
bad oddly, quite heavily asymmetric, via the US and Japan and in some cases
Europe. China-Australia via Europe is not very optimal.

It has to be said if you're trying to bypass DPI, speed isn't your main
concern. I tolerated pretty low packet rates. If I had to VOIP it would have
been awful

------
alecbenzer
What's the point of confidentiality for DNS? Can't an attacker pretty easily
get IP-to-DNS mappings to discover who you're talking to? I guess not in the
case of VPNs/TOR?

~~~
kromem
Not in the case of Tor, but also not in the case of almost all/most cloud
hosted services.

For example, consider that Cloudflare proxies about 10% of the Internet. Well,
if you request a site they proxy, and DNS is in the clear, it's obvious who
you are connecting to.

But if you request a site and the DNS is encrypted, you could be visiting any
one of 10% of the sites out there.

Similarly, if hosting on AWS or Google Cloud platform, there's a LOT of other
services hosted in those IP blocks, and IPs change frequently, so there's a
significant degree of ambiguity.

This is all in addition to fixing the threat of DNS leakage for VPN/Tor
connections.

~~~
dagenix
... except that SNI isn't encrypted.

~~~
kromem
Good point - I totally forgot about that.

So yeah - it mostly only matters for VPN/Tor traffic.

