In recent times, operating systems including Windows and macOS have been adding support for encrypted DNS. But how do the involved protocols work? And what are their benefits?
To understand them, we first have to look at the Domain Name System (DNS) itself, which is one of the fundamental backbones of the Internet. However, DNS alone does not provide any encryption or authentication, which makes DNS communication vulnerable to eavesdropping and in-transit modifications. Adversaries can use DNS information in cache poisoning attacks to lure victims on phishing websites. On a larger scale, state-level agencies can use pervasive monitoring of DNS for surveillance purposes and therefore attack users‘ privacy. Other third parties can use DNS data for Open Source Intelligence (OSINT) purposes, which may harm users‘ security altogether.
Encrypted DNS protocols were first introduced in 2008 when Daniel J. Bernstein proposed DNSCurve. In the following years DNSCrypt followed but both protocols failed to gain noteworthy adoption. In hindsight of the Snowden revelations in 2013, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) were developed and standardized by the IETF. They aim to secure DNS by adding confidentiality, integrity and server authenticity.
But how do these protocols work? Let’s have a short look at each.
DNS-over-TLS
DoT, described in RFC 7858, is using the well-known Transport Layer Security (TLS) protocol and thus inherits all its security benefits. By default, DoT resolver listen on port 853 for incoming DNS queries that must be encrypted. This non-standard port was chosen to ease the differentiation between DoT and non-DoT connections. However, administrators deploying DoT can choose a different port, provided that both resolver and clients agree. A fallback to cleartext DNS messages within the protocol is not allowed, neither for the client nor the server.
The protocol, as shown above, consists of two Round-Trip Times (RTT) on first contact. First, the DNS client performs the TCP handshake with the resolver it has chosen to connect to. Next, the DNS client performs the TLS handshake with the server. The client does not necessarily have to authenticate the server as this depends on the used profile. Therefore, self-signed certificates are also acceptable. After the successful completion of the handshake, both parties obtain a session key that is used for subsequent packets. In a third step, the DNS client sends its DNS queries through the established TLS channel. Multiple DNS queries may be pipelined to reduce bandwidth. Messages sent through this TLS channel are hidden from any intermediate party; therefore the DNS queries and answers stay confidential, with any Manipulation detectable.
Privacy Profiles
DoT supports two usage profiles that are defined in RFC 8310 and differ in the privacy they provide. Clients can choose which profile to follow and can thus match their DNS settings to their requirements. Administrators can also force the use of a usage profile.
- Opportunistic: This profile does not guarantee privacy but tries to achieve as much as possible. Therefore, if connections to servers cannot be authenticated or encrypted they are still acceptable for the client. This profile consciously rates availability as a primary and privacy as a secondary goal and can thus result in insecure connections.
- Strict: This is a privacy-oriented profile and does not allow establishment of connections to servers that cannot be encrypted or authenticated. It restricts availability but guarantees privacy of DNS messages. A fallback to insecure connections is prohibited.
Use of the strict privacy profile is recommended to establish adequate security in most settings.
DNS-over-HTTPS
DoH, as described in RFC 8484, is the most recent standard for encrypted DNS and uses HTTPS sessions to exchange DNS messages. This enables masking within other HTTPS traffic.
DoH uses URI templates to send DNS requests and can either use GET or POST methods. When using Cloudflare’s 1.1.1.1 resolver, the requests are structured as followed:
- The GET request is sent to https://1.1.1.1/dns-query?dns, where the value of the DNS parameter contains the DNS message encoded in base64url.
- The POST request is sent to https://1.1.1.1/dns-query within the message body. In addition, the header application/dns-message is specified.
It is interesting to note that the RFC does not specifiy the path dns-query. However, lists of public resolvers show that resolvers generally follow this format. Web browsers are able to conduct the requests on their own as they ship with an HTTP engine. An example GET request that recursively resolves the domain name www.hisolutions.com is shown below:
https://1.1.1.1/dns-query?dns=AAABAAABAAAAAAAAA3d3dwtoaXNvbHV0aW9ucwNjb20AAAEAAQ
The answer includes the corresponding IPv4 address of the resolved domain. For more information about the structure of DNS messages, refer to RFC 1035.
Overall, the DoH protocol works similar to DoT. Their protocol messages include the same content, except for the additional wrapping of DoH messages. However, this wrapping in combination with operating on the same port as common web traffic yields additional privacy benefits that are discussed below.
Discussion
DoH offers the best privacy guarantees of the encrypted DNS protocols. The use of the common port 443 could help prevent censorship of DNS lookups, as third parties observing the traffic are not able to differentiate between regular web and DNS traffic. Therefore, they must block access to the full website to block DNS lookups. A blacklist only works partially as it can only block the access to well-known DoH resolvers. Another point includes the additional masquerading of DNS messages through the use of HTTP. This decreases the likelihood of successful fingerprinting through observing third parties. On the other side, DoT does not interfere with common web traffic by operating on a dedicated port. This enables adversaries to simply drop traffic on that port, such that clients must switch to an (insecure) alternative. However, in managed environments this may be done on purpose, e.g. to force the use of predefined resolvers.
Both protocols add a performance overhead compared to traditional DNS. Although researchers found higher response times for individual DoT/DoH queries, page load times performed similar to traditional DNS given stable network connections. When network conditions degraded, traditional DNS significantly outperformed DoT/DoH. However, this is critique on a high level and the elevated response time is rarely noticeable on the user side.
Usability of both protocols has increased over time, and further adoptions are already planned. As of now, DoT/DoH is already available in Firefox, Chrome and Opera, and therefore supported in the most common web browsers. When it comes to operating systems, both Windows and macOS have added DoH to their pre-release channels and are planning to release it anytime soon. On mobile, Android has been supporting DoT since Android 9. Overall, users are mostly able to enable encrypted DNS on their devices.
We performed some measurements on the Internet and found that, while the number of users of DoH has increased significantly over time, the number of DoH resolvers has not. This highlights a consolidation in the DNS resolver market, which can be problematic in case of untrustworthy resolvers. Even for trustworthy ones, it introduces a single point of failure that other systems rely on, as a recent Cloudflare outage showed. Therefore, the defined secondary resolver should not be of the same provider as the primary one. When using open resolvers we recommend the use of resolvers that have clear privacy directives, prove successful third party audits and have a clean compliance history.
In the future, other encrypted DNS protocols such as DNS-over-QUIC (DoQ) may be used as well. They will probably increase in adoption once HTTP/3 starts rolling out, but DoQ does not include additional privacy benefits as long as most web traffic is still conducted over HTTPS.
