Image for post
Image for post

Oblivious DNS Deployed by Cloudflare and Apple

Nick Feamster
Dec 9, 2020 · 5 min read

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 34.200.129.209. 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.

Image for post
Image for post
DNS queries are often specific to devices. Thus they can allow an observer to determine which devices are connected to a particular network.

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:

Image for post
Image for post
The Oblivious DNS protocol, which mirrors the ODoH Protocol outlined in the ODoH draft. Figure 1 in the ODoH paper is essentially the same, except the recursive is called a “Proxy”, the ODNS resolver is called a “Target” and the Name Server is called a “Resolver”. The operation is the same.
Image for post
Image for post
In Oblivious DNS, the local recursive DNS resolver sees the IP address that issued the DNS query, but not the name. The ODNS authoritative server sees the name, but not the IP address that issued the query. No party sees both.

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.

Image for post
Image for post

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.

Noise Lab

News from the University of Chicago Network Operations and Internet Security Lab

Nick Feamster

Written by

Neubauer Professor of Computer Science, University of Chicago. The Internet, research, running, & life. https://people.cs.uchicago.edu/~feamster/

Noise Lab

Noise Lab

News from the University of Chicago Network Operations and Internet Security Lab (https://noise.cs.uchicago.edu/)

Nick Feamster

Written by

Neubauer Professor of Computer Science, University of Chicago. The Internet, research, running, & life. https://people.cs.uchicago.edu/~feamster/

Noise Lab

Noise Lab

News from the University of Chicago Network Operations and Internet Security Lab (https://noise.cs.uchicago.edu/)

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store