DNS Over HTTPS: The Big Privacy Win Behind This Acronym Soup

Google and Mozilla both recently announced plans to encrypt users’ browsing data when they visit websites with Google Chrome or Mozilla Firefox. The companies are rolling out a technology called DNS over HTTPS (or DoH for short, and yes, that’s an acronym containing two more acronyms) in their browsers. DoH uses encryption to hide the interactions between your computer and other servers across the internet that happen when it connects to every website you visit. Those interactions are routinely monitored by people listening on the wire and can be used to profile you for advertising, and potentially for far worse.

This move to improve users’ cybersecurity and privacy has been met with a number of criticisms. Internet service providers and child safety advocates have proffered scary warnings of massive cybersecurity threats and harms to children. It’s extremely important that DoH is done right, and that’s why the browser companies are taking steps to make sure their implementations address these concerns.

Before getting into the actual risks and their solutions, it’s helpful to have some background on the systems themselves, since terms like “DNS” and “HTTPS” are both just a letter soup to a lot of us.

The Domain Name System (DNS) is one of the old guard protocols of the internet. First defined by the Internet Engineering Task Force (IETF) in 1983, DNS is a well-defined method that computers use to find out the machine-friendly location, called an IP address or just an address, associated with a human-friendly identifier, called a domain name. In other words, it describes the process your computer must follow to find out the computer-readable address for a website like newamerica.org. IP addresses might look like 99.84.104.73 or 2600:1403:2:29c::2add. You can see why remembering something like newamerica.org is preferable for us human beings. The DNS is often referred to as the “phone book” for the internet, and while it is more complicated than your standard phone book, the analogy isn’t far off.

The DNS relies on a few different types of servers. The first, and most relevant to DoH, are called “recursive resolvers,” and they’re the front line DNS responders. Your computer learns about them from whatever network you’re connected to and, unless you’ve purposefully changed your settings, they’re probably run by the internet service provider of whatever network you’re using. These servers take a DNS query (like newamerica.org) from your computer and return information about what server to ask next. Each server in the chain narrows down your query bit by bit. The process starts with one of just a handful of “root” DNS servers (so called because they sit at the bottom of a tree-like system), then moves to the servers responsible for the “top level domain” (such as “.org” in our example) in the query, and finally to the server that holds the answer you’re looking for—New America’s IP address, 13.249.44.33, in this case.

Because most servers on the internet don’t change their machine address very often, the intermediate servers can keep recently requested answers in their memory for a while (anywhere between 30 seconds and 24 hours is common). This means that servers don’t have to do that whole song and dance every time someone types “newamerica.org” or “google.com” into their web browser. For most queries, the whole process of looking up the address takes something on the order of tens of milliseconds.

Unfortunately, the DNS comes from the early days of the internet before engineers added privacy and security as fundamental items on the protocol development checklist. The early designers thought of the internet as primarily an educational tool and didn’t anticipate the cybersecurity and privacy challenges that we face almost 40 years later. As a result, the requests and responses between your computer and all of those DNS servers are sent unencrypted, just as emails and web pages used to be.

The DNS is not the only example of this problem. Other internet protocols that were designed without encryption the first time around have had to be reengineered over the years once the internet standards community realized that they were insecure, not workable for commercial purposes, and leaked personal data. For example, over the last 25 years, a large group of engineers, advocates, cryptographers, and others have put in a ton of work designing and implementing the HyperText Transfer Protocol Secure (HTTPS) to replace the original HTTP. This makes web browsing private by encrypting the connection between the browser and the web server it is connecting to.

Many of those same people are now turning their attention to the DNS. This is important work, because while domain name lookups can seem like esoteric bits of deep internet infrastructure, they can reveal profoundly personal information. The domains that users type into their browsers can show their interests and connections on a wide range of issues, including their religious and political beliefs, sexual orientation, and financial status. In addition, unencrypted DNS can leave users open to attacks that attempt to trick the browser into visiting a site that the user did not intend to visit. Thus, safeguarding the DNS system can provide critical protection for personal privacy as well as enhance cybersecurity.

This takes us back to DNS over HTTPS (DoH), which is one technique for securing the DNS—and it is a fairly simple change. Browsers that implement DoH use the HTTPS protocol to connect to the recursive resolver rather than using the insecure DNS protocol. HTTPS already has tried and tested encryption built in. This simple change is what Chrome and Firefox are experimenting with.

Critics such as internet service providers and child safety advocates have argued that implementing DoH will cause harm, because observing and recording DNS requests has been a solution to certain problems. In particular, they cite the need for companies to be able to monitor their own networks and the need for parents to be able to block their children from some online content. However, neither of these concerns—while valid—present a reason to prevent implementation of DoH, which provides important privacy and digital security protections. In fact, Google and Mozilla are directly addressing these potential scenarios in designing their DoH offerings.

So, how are Google and Mozilla planning to offer DoH? The Chrome browser team is currently planning an experiment (they have not yet announced an exact start date) to begin using DoH through a small number of pre-selected recursive resolvers. Under the pilot, Chrome will upgrade DNS queries made by Chrome to use DoH only as long as the user has already configured their computer’s DNS to use one of a handful of recursive resolvers that are offering DoH capabilities. The list of DNS providers that Chrome will upgrade is publicly available. So, if a user has changed their networking settings on their computer to use, for example, the recursive resolver at 9.9.9.9, Chrome would use DoH instead of unencrypted DNS to reach the same server. The recursive resolver at 9.9.9.9, which is on Chrome’s list, is run by a company called Quad9, and it uses the DNS to block malicious websites for its users.

The Chrome pilot program addresses the above concerns by functioning as an opt-in feature: if the user has not changed their ISP-assigned DNS server, Chrome will not turn on DoH. Thus, businesses that want to maintain their ability to monitor their own networks, and parents who want to maintain their ability to monitor their children’s online activity, will continue to have that option.

Firefox is taking a different approach that is more broadly applicable, but that appears to be carefully crafted to impose the least disruption for everyone from enterprises to parents. Firefox already offers an option to use DoH hidden in its settings pages, but recently began rolling out a prompt explaining the technology and asking if users want to enable DoH. Users will also have the option of selecting the recursive resolver they’d like to use, choosing from any organization that is participating in Mozilla’s “Trusted Recursive Resolver” program. At the time of writing, only Cloudflare is on that list, but Mozilla is in talks with others and that number will likely grow.

In addition to letting users choose whether to enable DoH, Firefox has designed its system so that the DoH functionality will not activate in certain circumstances. First, if Firefox is enterprise-administered (and thus configured by a corporate IT department), it will not prompt users to enable DoH at all—though enterprises can still decide to turn it on as a matter of policy. Second, if Firefox detects that parental control systems are in use on the computer, it will not use DoH. Finally, Firefox is setting up an option for organizations to indicate that they want to prevent the use of DoH on their network. Specifically, these organizations can block access to a dummy domain name created by Mozilla solely for the purpose of being blocked from within the organization’s network. When users on that network use Firefox, the browser will first attempt to reach that dummy domain, known as a “canary domain.” If Firefox cannot reach the domain (because the organization has blocked it through this opt-out mechanism), Firefox will not use DoH. Thus, any organization that wants to block DoH, but for whatever reason can’t use either of the prior solutions, can simply block access to the canary site and prevent Firefox from using DoH. The use of the canary domain isn’t an ideal solution—it’s a bit convoluted—but Mozilla acknowledges it as a stop-gap measure until there are broadly agreed upon methods of indicating DNS preferences in a simpler way.

Thus, both Chrome and Firefox have taken steps to mitigate the risks that DoH might raise, both for enterprises concerned about their ability to monitor their own networks, as well as those who fear the new system will affect online parental controls. These new privacy-protecting features have been under development, with input gathered from the relevant stakeholders, for 18 months or more. The result is a pair of systems that appear to be carefully crafted, and that will protect the privacy and security of millions of everyday users.