DNS over TLS: The Whats, Whys, and Hows [Explained]

DNS has been at the heart of infrastructure since its inception in 1985. It is responsible for resolving human readable names to the IP addresses used by computer software.

Even though DNS was one of the first layer 7 protocols in wide use, it’s one of the last to be widely encrypted. After all, unlike with HTTP, nobody is sending banking information over DNS. It’s analogous to SMS conversions and the metadata around those conversations.

Does it really matter if an attacker listening on the wire knows who talked to whom, if they can’t derive what was said?

In 1985, the answer was a resounding no. Let’s set the stage: the Morris worm, widely regarded as the harbinger of computer security, wreaked its havoc across the net in 1988. Before that, people trusted that others would follow “netiquette” for the sake of mutually advancing ourselves.

Today, with ransomware around every corner, and phishing links in every inbox, this seems insanely naïve.

Regardless, between then and now we’ve seen a massive uptick in encryption for our favorite protocols. SMTP is now largely secured as it moves across the WAN. HTTPS is far, far more common than HTTP.

But what then of DNS? As we’ve become more privacy conscious, those in the tech community have realized the importance of encrypting even the metadata around communications. After all, altering DNS is a popular way for administrators to block traffic.

It can be used by shady ISPs to introduce advertising into communication streams. We’ve reached a sort of nexus of consensus around this issue. An Australian SSL Certificate Provider named DNS over TLS one of the “technologies to watch” for 2019.

What then is DNS over TLS?

SSL/TLS is a protocol used for tunneling other, arbitrary protocols over a secure connection. It uses a mix of both asymmetric and symmetric cryptography in order to accomplish both strong security and performance.

As of Android 9, the mobile operating system provides native support for DNS over TLS. This means that any queries sent over the wire are encrypted in transit. For your average person, this is a huge step in the right direction.

However, because DNS is inherently a hierarchical system, and often hosted by another entity, that party who decrypts the traffic on the other side is still aware of your queries.

In addition, DNS over TLS operates by default over port 843. By blocking this port, providers can force your software to “fallback” to insecure DNS. An alternative to DNS over TLS, DNS over HTTPS can potentially solve the second problem, but not the first. DNS over HTTPS tunnels those DNS queries over the HTTP protocol.

In some ways, this is an additional privacy boon even over DNS over TLS. Mozilla does an excellent job of describing this technique. Architecturally, it is not favored as it adds complexity. While you CAN tunnel one protocol over another, there’s a performance penalty for doing so, and wrapping protocols up into each makes them harder to alter in the future.

DNS over TLS is likely going to be what winds up winning out if history is a good predictor of the future.

How can we mitigate our ISP from having this information though?

One option is to pick a trusted third party. Cloudflare supports DNS over TLS on their 1.1.1.1 resolver. Another option is to self-host a recursive DNS server, ideally on a VPS which does not store customer data. Researching such a VPS will be left as an exercise to the reader, however, even once such a VPS has been obtained, there is still the issue of software which supports DNS over TLS.

At the time of this writing, DNS over TLS is bleeding edge enough that BIND, the internet’s most popular DNS server, does not natively support DNS over TLS. We can however, leverage software called STUNNEL to serve as a TCP proxy at layer 4 of the OSI model.

This procedure is described in the ISC documentation.

It is important not to confuse DNS over TLS with DNSSEC, an older technology which cryptographically signs (but does not encrypt) DNS data, and is useful from the perspective of ensuring that DNS wasn’t modified in transit.

At first glance this is a somewhat overlapping aim, as SSL/TLS insures integrity of the information in transit and verifies the identity of the server by way of a publicly signed certificate, but DNSSEC has other tricks up its sleeve that are out of scope for DNS over TLS. DNSSEC includes a technology called DANE, which, similar to CAA records, allows an administrator to provide a short list of acceptable Cas that can vouch for their domain. DNSSEC also provides a sort of separation of duties for larger organizations.

Even if someone has administrative permission to the DNS Server to make updates, without also having permission to the private key, they cannot sign the zone. All in all, DNSSEC still has some, but less value when used in conjunction with DNS over TLS.

As time marches on, organizations that currently rely on DNS based manipulation to protect their users might switch to full-on deep packet inspection by terminating the SSL/TLS connection at their edge.

As this technology matures, will it become a common practice to proxy the connection to the DNS server itself? A lot is still yet to unfold with the rapid changes to technology in this space, but one thing is for sure: DNS over TLS provides a more secure and privacy focused internet for us all.