Over the past several years, our research group has been exposing the various privacy risks of Domain Name System (DNS) traffic and developing mechanisms to improve DNS privacy.
Briefly, the DNS is the Internet protocol that maps a domain name like uchicago.edu to an Internet address, such as 22.214.171.124. The DNS has been used for many purposes over the years beyond simply Internet name lookups. For example, it has been used to implement so-called DNS-based blocklists which are critical to fighting spam and malware; additionally, monitoring DNS itself has become critical to many aspects of Internet security, as the presence of malware or infection on a network can be the first indication of compromise.
Unfortunately, the DNS also carries privacy risks: In 2016, we demonstrated that DNS queries can reveal information about the devices connected in your home. In 2017, we showed how DNS queries could allow an observer to determine which websites a user was visiting—even if the user was using a VPN or Tor. In particular, our research found that 40% of Tor’s exit nodes by bandwidth were using Google public DNS to resolve DNS queries, thus giving Google significant visibility into the traffic on the Tor network, across all users.
Since discovering these critical privacy threats, various stakeholders have suggested that changing the party that resolves DNS queries—the so-called “local recursive resolver”—could result in improved privacy. However, changing local recursive resolvers—say, from the default resolver to a public DNS resolver (such as those operated by Google or Cloudflare, for example) doesn’t solve the problem; rather, it only changes the party that one has to trust, from your Internet service provider to the operator of a public resolver.
In 2018, we—Paul Schmitt, Annie Edmunson, Allison Mankin, and I—figured there might be a way around this, if there were some way for a resolver to resolve a DNS query without knowing who (or, specifically, which IP address) issued the query. To achieve this goal, we designed and implemented Oblivious DNS. Oblivious DNS decouples the DNS query and response from the IP address of the “stub” resolver (i.e., client device) that issued the query. The process proceeds in three steps:
- The client’s stub resolver encrypts the query name (QNAME) of the DNS query (e.g., uchicago.edu) before sending the query to the local recursive resolver.
- The client’s stub resolver appends “.odns” (or some authoritative top-level domain) to the resulting encrypted QNAME, thus generating a referral to the recursive Oblivious DNS server that will ultimately resolve the query.
- The Oblivious DNS server has uses its corresponding private key to decrypt the encrypted QNAME and performs a recursive DNS resolution as normal. It sees the domain name, but not the IP address of the client stub resolver that issued the query.
We first presented Oblivious DNS at the DNS-OARC operator group in March 2018, and subsequently published the work at the Privacy Enhancing Technologies Symposium in 2019. We also presented the work at the IETF as an Internet Draft in the DNS Privacy (DPRIVE) working group.
At the July 2018 IETF where we presented the ODNS draft, the first designs for DNS-over-HTTPS (DoH)were also proposed. Shortly thereafter, Firefox began testing versions of DoH in its browser, using Cloudflare as its (only) Trusted Recursive Resolver (TRR). Subsequently, other TRRs have been added, although Cloudflare remains a primary TRR.
DoH solves an orthogonal set of problems by encrypting the DNS transport, but the resolver that terminates the DoH connection must still be trusted: it sees both the decrypted query and the IP address of the client that issued the query. As a result, an operator of a TRR could ultimately see all of the same information that any passive eavesdropper of unencrypted DNS could see. Certainly encrypting DNS queries is a good thing for privacy, but DoH by itself hardly solves the problem.
Today, Cloudflare announced Oblivious DNS-over-HTTPS (ODoH), which essentially combines our Oblivious DNS protocol with DNS-over-HTTPS.
Sending Oblivious DNS queries via HTTPS rather than unencrypted UDP has some advantages that makes the protocol simpler. Specifically, ODNS had to worry about exchanging keys in the queries themselves, and the encryption of a QNAME sometimes resulted in ciphertext that was too long to fit in a QNAME once the “.odns” top-level domain suffix was appended. ODNS also needed to use the bits for letter case to encode extra bits, thus making certain DNS enhancements like 0x20 encoding (a defense against DNS cache poisoning) impractical.
Because ODoH uses HTTPS as transport, it can avoid some of these issues that ODNS faced. The performance evaluation of ODoH also mirrors that of ODNS. Below we see that ODNS imposes some overhead on time to first byte for a web page load—mostly because of the additional latency incurred by the network hop between the local recursive and the ODNS server. The ODoH draft does not explore time-to-first byte, but shows the impact of web page load time as similar, as we also show in the ODNS paper.
It is exciting to see ODNS deployed in practice using HTTPS as transport. Using HTTPS as transport indeed solves many of the practical issues that ODNS faced, involving the size of encrypted QNAMES, support for EDNS0 client subnet, 0x20 encoding—features that need to be supported for a practical deployment.
Some challenges do remain. In particular, our research on DoH performance, and more recent research from Josiah Chavula and Enock Mbewe has shown that DoH performs poorly when network conditions are poor. Naturally, those effects carry over to ODoH. We look forward to continued research and development in this area towards improved performance of ODNS, DoH, and ODoH. One effect we observed in our ODNS work is that as the footprint of ODNS resolvers increases, the performance overhead of ODNS will decrease, because the network latency of the additional network hop will be lower for an increasing number of users. Cloudflare’s adoption and deloyment of ODNS will surely help make this a reality.
Our research lab at the University of Chicago continues to advance the field of DNS privacy, including exploring ways to “re-decentralize” DNS (and DoH) queries across multiple trusted recursive resolvers to make it more difficult for any TRR operator to observe all of a client’s DNS queries, as well as to improve the resilience of the private DNS ecosystem.