DNS privacy: DNS-over-TLS

DNS-over-TLS (DoT for short) is a standard developed by the IETF (under the RFC 7858 designation) to solve privacy concerns in DNS communication.

DNS Privacy: a primer

As we’ve talked about before, until recently,  DNS has been done in cleartext: the queries and responses between both the end user (applications, or stub resolvers, such as a browser) and the (first-hop) DNS resolver and the resolver and the DNS nameserver(s) are unencrypted by default.

While DNSSEC extensions were developed early on, they only added response integrity and not privacy. As the IETF states, “either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private.”

In recent years, however, that changed. Privacy has become a central concern and addressing it has spawned numerous solutions, such as DNS-over-TLS.

DNS-over-TLS

DoT approaches privacy by encrypting DNS queries and responses between entities (predominantly between the stub resolver and the first hop resolver) using TLS (Transport Layer Security).

DoT uses a standard port (853) to initiate and accept DNS queries. It is possible to use a mutually agreed different port, but it is not the default. Once the connection is made, a TLS handshake is attempted, and after authentication the encrypted DNS communication can commence.

DNS servers supporting DoT are not accepting unencrypted data on the designated port, neither during session initiation, nor after a failed TLS authentication.

DoT overhead

Computers are powerful and efficient, but not without limits. DNS-over-TLS adds latency to DNS operations that needs to be accounted for and minimized.

DNS clients are required to adhere to a certain field length (two octets) and it is recommended to keep established, but idle, connections alive to the server. Another way to minimize latency is to pipeline multiple queries over the same TLS session. In this case, it’s the DNS client’s responsibility to match responses to queries, as they may arrive and be answered out of order.

Keeping established connections alive helps distribute the connection setup costs. Misconfigured handling of idle connections can lead to denial of service issues.

Flavors of DoT

DNS-over-TLS can be used in various ways. The IETF standard identifies opportunistic and Out-of-Band Key-Pinned privacy profiles.

Opportunistic privacy profile means the client recognizes a TLS-enabled DNS resolver and attempts to use it. If it successfully validates it, DNS-over-TLS may be used, but isn’t mandatory and the client can fall back to non-encrypted DNS.

Out-of-Band Key-Pinned privacy profile is usable where the trust between stub and recursive resolvers is already established. Enterprise DNS is one good example. With this profile, DNS clients authenticate servers by a set of (previously distributed) SPKI Fingerprints.

DoT pros and cons

DNS-over-TLS addresses privacy, but not the security of DNS operations. It is important to note that DNSSEC and DoT are not mutually exclusive, but rather compatible protocols that complement each other.

DoT is a straightforward protocol, and fairly easy to implement. TLS authentication is a mature, trusted, and well-maintained technology for encryption. But DNS-over-TLS also presents a number of challenges and concerns.

Attacks against TLS itself, such as protocol downgrade, affect DNS-over-TLS. DNS resolvers offering DoT have to be aware and be patched against TLS vulnerabilities. DNS clients can, in order to defend against person-in-the-middle attacks, discard cached data from a server stored in cleartext.

DoT isn’t fully protected against traffic analysis and SNI leaks. (Although it is in constant development to patch these vulnerabilities.) Split horizon DNS, where the DNS response may be different based on the source of the query, is also known to experience issues when used with DoT.

Network managers for both private networks and public services need to learn more about DNS privacy, DoT (and DoH and other implementations), and the solutions, and challenges, they present for their work. Education about these protocols is also important for end users — both for owning their privacy and to avoid issues resulting from unintentionally harmful configurations brought to a network.

DoT, DoH, and other protocols are in constant development, offering ways to influence their evolution. All network managers and architects, whether they’re running public or private infrastructures, should participate in pilot programs to discover and best voice and address their challenges and requirements.