Encrypt all the things, DNS included!

Foundation for Applied Privacy

2019-03-29 20:52

tldr; Today we are launching our new DNS Privacy Services supporting the DNS-over-TLS and DNS-over-HTTPS protocols.

DNS traffic is revealing

DNS is an old protocol that has been around for over 30 years. The scalability of DNS still serve us well even on today's internet size but the protocol is lacking confidentiality properties. With successful efforts like Let's Encrypt that significantly increased the share of encrypted HTTP traffic the cleartext nature of DNS is becoming more of an issue that needs to be solved since it is one of the few remaining ways how observers can learn the sites visited by an internet user. DNS traffic can reveal a lot about a user, it basically discloses the entire browser history at a domain level.

There have been multiple efforts to protect DNS traffic and in the last few years these efforts also included protocols that got specified in RFCs.

DNS-over-TLS

In 2016 DNS-over-TLS also known as DoT got published but its adoption remained relatively low and some implementations still have some significant deficiencies like establishing a new TLS connection for every single DNS query instead of reusing a connection for multiple queries to reduce the connection setup overhead. Luckily this is slowly changing, as an example Android 9 ships with DoT enabled by default. Even the default opportunistic mode that does not authenticate the TLS connection to the resolver is still positive progress. We hope to see DoT software evolve in particular with regards to connection handling and TLS authentication.

DNS-over-HTTPS

The second protocol, DNS-over-HTTPS also known as DoH, published in October 2018, has seen fast adoption particularly from browser vendors. Mozilla Firefox experimented with DoH already before the RFC got finalized. At this point users can opt-in to use DoH but Mozilla expressed intentions to enable DoH by default eventually. Google Chrome will also ship DoH support but does not have a user interface to enable and configure it yet.

From a pure protocol perspective we prefer DoT over DoH because it contains less unnecessary metadata (no HTTP and all the potential issues that come with it). We do support both protocols because we want to bring encrypted DNS to the users and at this point it is a lot easier to enable DoH in a browser than to install and configure additional software that talks DoT with the resolver.

And there is a small but important implementation-specific dependency: Firefox unfortunately requires using DoH for DNS to make use of encrypted SNI. You can not use ESNI while using a system wide DoT resolver because Firefox needs to retrieve the keys for ESNI via DNS and it only supports DoH for that (no DoT). ESNI (an active Internet-Draft) will close another loophole disclosing the visited sites at the TLS layer. The dependency to use DoH for DNS is not a requirement by ESNI but a shortcoming of Firefox and we are not sure whether this will change anytime (soon).

Some of the concerns voiced around DoH are not directly about the protocol itself but rather about the way how applications (mainly browsers) might select the DNS resolver since Mozilla partnered with Cloudflare to provide the DoH server capacity. Some other big players might simply fear loosing access to lots of DNS data that they got for free until now.

We share concerns about centralization but that should not be used as an argument against the protocol. It is important that DoH client sofware offers users an option to select their preferred DoH server and that more resolver operators offer DoH and DoT support, which brings us to the next point.

With browsers implementing DoH, the client portion is well covered, but for resolver operators the DoH software options are currently still looking dire. At the time of writing no major resolver software ships a released version with DoH support yet which makes it harder to offer and operate DoH servers but we like to hope that this will change within the next few months.

The actual goal behind all of this

Users should be able to browse the web privately without an observer learning all the sites they visit. Even with encrypted DNS this goal is not met yet. Observer can still learn visited domain names after a user enabled DoH or DoT due to information disclosed in TLS (SNI) but encrypted DNS is nonetheless a requirement towards protecting that information until the specification for encrypted SNI is completed and implementations are made available.

Our DNS Privacy Services

We operate public DNS Privacy resolvers in the following flavors:

two DoT endpoints
an experimental DoH endpoint
an experimental DNS-over-Onion endpoint

(we do not offer plain DNS over UDP endpoints)

More details can be found on our service page.

If you'd like to know what we log and for how long you should have a look at our privacy policy.

A few months ago when we decided to offer DNS privacy services for the general public as our next privacy enhancing service we didn't anticipate the attention this topic is getting these days. We are glad DNS privacy is gaining traction.

If you would like to learn more about these DNS privacy protocols come to our talk "DoH, DoT, what? - An Introduction to DNS Privacy Protocols." at easterhegg 2019 in Vienna (19.04.2019).