DNS over TLS (DoT)

The Privacy Problem

It is no secret that the original DNS design did not take security into account. While DNSSEC addresses many of the security short comings of the traditional DNS design, especially in server-to-server communication, it falls short in adequately addressing the “last mile” problem, that is the communication between DNS client (such as a mobile phone) and its nearest DNS server (such as the corporate or ISP DNS server).

Truth be told, there are two major reasons why DNSSEC is the wrong tool for this job:

• DNSSEC does not encrypt traffic: DNSSEC uses public key cryptography to provide authentication and data integrity, so we know precisely who sent the data, and whether or not that data changed during transmission. However, it does not provide any privacy, meaning someone eavesdropping on the wire can still see all of a DNS message in the clear; it is just extremely difficult for them to alter the data.
• DNSSEC validation is resource intensive: DNSSEC validation requires more computing power and network queries to fully validate an answer. While it is possible to have the client perform all of these queries itself, we do not do it for the same reason why we have a local DNS server: so nearby clients can share the resources and cache of the server, and spare themselves the busy work. Just imagine if a mobile phone could not rely on a DNS server to perform all the queries and lookups, but rather had to handle all of the lookups itself AND perform full validation on each answer, it would likely drain its battery so quickly that it would render the device less useful.

To fill this big gap that is the “last mile,” many competing technologies have emerged over the years, such as DNSCurve and DNSCrypt. While these technologies try to bring privacy between DNS client and server, they have one thing in common: they are proprietary and non-standardized. The standards body IETF (Internet Engineering Task Force) recognizes the need for DNS privacy, and released two new standards in 2016 that address these needs. In this article, we will be discussing one of the two new standards, DNS over HTTPS, or DoH as it is commonly referred to. It also has drafts being worked on for both Confidential DNS, and IPSECA

DoT basics

To understand DoT, we first need to understand TLS, Transport Layer Security. Many people may know this technology by its former name, SSL (Secure Socket Layer). SSL started in the 1990’s and lived to see version 3.0, before major deficiencies in the protocol itself took it down. The enhanced replacement was TLS, and the version number started back up at 1.0 again. While the latest version of TLS is 1.3 as of this writing, DoT was largely based on version TLS 1.2.

In a standard TLS communication, the client reaches out to the server, obtains the server’s certificate (usually a X.509 cert), and runs through the standard certificate authority validation process to decide whether or not it trusts this server, i.e. is it signed by a certificate authority the client trusts, etc. This is an important detail that deserves highlighting, and we will discuss its impact later. After the client decides to trust the server, they negotiate an encryption key, and are ready to start encrypting data. This is known as a TLS handshake.

RFC 7858 specifies that DoT uses TCP port 853¹ for secure DNS communication. Just like any TLS-based communication, a DoT DNS client first reaches out to the DoT-enabled DNS server on port 853 and performs a TLS handshake. The DoT client receives the server’s certificate, somehow validates it (more on this later), then generates a symmetrical encryption key that they both agree on (such as AES) for the actual data encryption. In short, DoT uses the same technology that your web server certificate uses, it just runs over a different TCP port.

DoT has two operation modes, a strict mode², and an opportunistic mode. In the strict mode the DoT client has a list of trusted DoT server certificates, and only communicates with trusted DNS servers. In the opportunistic mode, the DoT client attempts to talk to any DNS server over TCP port 853, and when it fails to establish a secure communication channel, it falls back to using port 53 for traditional insecure DNS.

Like DoH, with DoT we can protect the communication for each hop between server-client or server-server, however, it does not provide the authentication and integrity checking that DNSSEC offers. Different from DoH, DoT can be deployed to secure server-to-server communication, making it a technology that protects beyond the “last mile.” These technologies are not mutually exclusive, they can be deployed to complement each other.

DoT Considerations

The biggest pro of DoT is that it encrypts; the biggest con of DoT is also that it encrypts. Let’s take a slightly deeper look.

DoT has the following characteristics:

• It encrypts
• It uses TCP
• It relies on certificates

Encryption/Privacy:

DoT grants privacy between two parties, meaning it is per-hop privacy. Your communication might be private between your mobile phone and your ISP, but it may not be between your ISP and its upstream DNS server. Privacy may sound like a good idea for end users, but when used in a controlled environment such as corporate network, it may cause more concern than benefits. Running a rogue DoT client in a corporate setting means that the IT or security team is unable to look into the DNS queries the client makes, be it that the client is visiting a known malware-infected domain, or is using (encrypted) DNS to exfiltrate sensitive data out of the corporate network.

Resource:

Using TCP has its own performance related concerns. Not only does it consume more resources (compared to UDP), it also opens the DoT server up to more TCP-based attacks. A DNS server that used to be able to handle 5,000 queries per second using traditional DNS, may only be able to support 1,0000 queries per second or less while running DoT.

Certificates:

Leveraging the existing technology of TLS has its down side, it brings DoT right back to the problem with certificate authorities (CA). During the TLS handshake, the client receives a certificate from the server, and the client needs to follow all the standard procedures a web browser would, to validate this certificate; this usually means by checking if the certificate is signed by a trusted root CA, or the certificate is self-signed. One possible solution is to leverage DANE to lessen the dependency on CA.

Why Use DoT?

While still early in its deployment stages, there are several vendors and companies offering DoT as a service, usually with their own client. For example, Google and CloudFlare both offer DoT services, and each has their own Android app to run as client. Open source projects such as stubby and Unbound provide desktop client support, and more options are in the works.

Just like DoH, if you trust the DNS service provider (such as Google), using DoT provides an extra layer of security between you and the service provider, just understand that communication between the service provider and the rest of the Internet could still be wide open and not secured by anything.

¹ RFC 8094 – DNS over DTLS uses UDP port 853 for its version of secure DNS communication.

² The formal name of the strict mode is “Out-of-Band Key-Pinned Privacy”, it uses public key pinning as described in RFC 7469.