Encrypted DNS: Why all the drama about DOH?

Two years ago, interest in DNS Encryption was lukewarm…

In May of 2018, ISC did a survey asking our users about their interest in deploying various DNS privacy measures, including both QNAME minimization and encryption (DNS over HTTP or DoH and DNS over TLS or DoT). At that time, although 29% of enterprise respondents were very interested in offering an encrypted DNS solution to their users, almost 75% stated they did NOT want to encourage users to use a free, public hosted DNS that implemented DNS privacy features. Among service providers, although just over half were very interested in offering encrypted DNS, a third of them cited LACK OF DEMAND as a significant obstacle to implementing it. (We are updating the survey now; click here to participate)

DoH has exploded with rapid development and deployment

Eighteen months later, the landscape is dramatically different. We now have a handful of browsers that implement encrypted DNS using DoH, many open, hosted DoH services, and there is a lot of pressure on enterprises and service providers to figure out what to do about it. Meanwhile, considerably less progress has been made in DNS over TLS, the main competitor to DoH. Google is implementing DoT support in the Android operating system, and there are some open source DoT resolvers. We don’t yet have stub resolvers that implement encrypted DNS in the desktop operating systems; the rapid drive towards encryption has been mostly in the browsers, not the operating systems. (Systemd apparently has DoT support, but it isn’t clear whether it works yet.)

What are the differences between DoH, DoT and ‘regular DNS’?

If you are confused about how DoH compares to DoT and to ‘regular’ DNS, you are not alone. This blog explains DoH and DoT in relation to actual privacy threats, which is critical for understanding what each does. At the kindergarten level, however, there are 4 main differences between DoH and ‘regular DNS’ illustrated below:

simple graphic showing client, dns server and web server
  1. Regular DNS (and DoT) are implemented in the operating system, and support all applications that need to connect over the Internet (including, for example, mail servers). DoH is typically implemented in the browser, in support of http only, although the operating system can also be configured with a proxy to direct all DNS over http.
  2. Regular DNS queries and responses are sent in cleartext, and may be read by someone intercepting them. DoH (and DoT) traffic is encrypted. This encryption provides protection against anyone wishing to read the contents of the DNS lookups, but note that there are still ways to discover what sites are being visited, despite encryption.
  3. Regular DNS responses typically are filtered through a DNS firewall that implements a ‘blacklist’ of sorts for zones with poor reputation for malware or abuse. This mechanism has evolved over a number of years, and there is no equivalent available for DoH at the moment.
  4. Regular DNS is typically provided by whomever administers the local network. The DoH resolver is currently configured into the browser, with some browsers coming pre-configured for cloud-based services.

In addition, although ‘Regular DNS’ has been proven to be very scaleable and reasonably low-latency, the scalability and latency of encrypted DNS is still being investigated. Regular DNS uses UDP (unreliable datagram protocol), which enables the application to accept packets in any order. Encrypted DNS uses TCP (transmission control protocol) which effectively establishes virtual connections with the server, using some finite server resources for each connection.

Who is advocating for DoH?

Privacy advocates are in general in favor of either DoT or DoH, because both protect against someone intercepting the DNS messages between the client and resolver. DoH is kind of the ‘web’ approach to DNS, so it is favored by people most comfortable with web servers. Google, Mozilla, Cloudflare and others are pushing fairly hard for users to switch from ‘regular’ DNS to DoH.

The impetus for DoH has not come from enterprises or from network access service providers; for the most part they are scrambling to catch up and figure out how to respond. Enterprises and service providers who offer DNS services today typically have network security features that depend on DNS, and no equivalent solutions for DoH. Because some browsers are threatening to enable DoH by default, perhaps offering the end user a hard-to-find or discouraging interface for opting out, enterprises are scrambling to figure out how to block DoH, and service providers feel pressured to deploy some DoH service option for parity with the hosted services providers.

Who decides which resolver your device queries?

There is an argument that DoH puts the end-user in charge of who will see their DNS data. In fact, the user can be in charge of where their DNS data goes with either traditional or encrypted DNS, but it is a question of what is the DEFAULT behavior. Typically, with classic DNS, the network operator (enterprise or service provider) establishes the network DNS service and the end user has to have some sophistication to override that system-level network setting and choose another DNS service. With DoH, the Browser selects the DNS resolver, and again, the end user has to have some sophistication to override that browser setting. The Firefox implementation includes pre-configured, centralized DoH providers, selected by Mozilla. While the end user can change this configuration, we all know that defaults are often left untouched. This means that by merely applying a browser update, the end user would unknowingly be switching DNS providers. (By contrast, Google has announced that if there is a network DNS server Chrome will not override that.) The proposed change in how the DNS service is provisioned and who controls that caused a lot of controversy. Advocates disagree strongly about whom to trust to operate the resolver at other end of the DNS connection. Browser-based DNS is clearly a way to take control from the user’s contracted, regulated, network operator and transfer it to a web-based service provider. If the end user is selecting this web-based provider, and trusts them, there is no problem, but if Mozilla or another browser vendor selects the provider, the end user might not have any relationship with, or trust in, their new provider. In fact, Mozilla has stated directly that their intention is to transfer control over DNS data from ISPs to their partners.

“We are trying to essentially shift the power to collect and monetize peoples’ data away from ISPs and providing users with control and a set of default protections,” he added, regarding Mozilla’s changes.

  • Marshall Erwin, senior director of trust and safety at Mozilla, as reported in VICE https://www.vice.com/en_us/article/9kembz/comcast-lobbying-against-doh-dns-over-https-encryption-browsing-data

Increased privacy is obviously good

The argument that a fast, forced migration to DoH is for the benefit of end users is hard to refute without seeming to argue against end-user privacy on the Internet, which is like arguing against motherhood. The problem is that while using DoH to encrypt from the browser to the cloud DoH provider will provide some additional privacy to the end user, overall, it does not seem to be in the best interests of anyone but the browser vendors and cloud providers to prefer DoH over DoT. Certainly, it is not in the interests of enterprises, whose top priority is ensuring network security and protecting the users and systems within their firewalls from malware and viruses. ISPs have legal obligations to block certain kinds of content, mandated by their regulators. In both of these cases, this blocking is implemented using DNS filtering that will be completely ineffective if users switch to DoH. Both enterprises and service providers who provide high-quality, large scale DNS resolution to their users today are also concerned about the scalability, performance and manageability of DoH. DoH runs over TCP rather than UDP: the scalability and resilience of UDP is well-established, while TCP can be considerably more resource intensive and sensitive.

What about the end users, though?

Aren’t encryption and privacy in everyone’s best interests? Of course, all things being equal, increased privacy is desirable. However, with DoH, other things AREN’T equal. There are increased security risks for users using DoH, because they are no longer protected by DNS filtering - and there are other, new security threats we are just discovering that are enabled by DoH. Some users who really need privacy for their own personal safety may be duped into feeling protected when using DoH, when actually using a VPN would provide much better privacy. DoH encrypts only the DNS lookup, whereas a VPN would protect all communications.

Deployment of DoH may contribute to increased centralization on the Internet

The biggest underlying concern about DoH, however, is the way the browser implementations can contribute to increased centralization of control on the Internet. This is because DoH makes it more likely that a key control point, the DNS, will move into the ‘cloud’ from the access network. This is a political and business issue, not a technical one. The Internet has thrived in part because of intense, open competition for better and more attractive services and applications. This intense competition is due to the openness of the Internet, its lack of regulation, and the lack of centralized control. There is a relatively low barrier to entering the markets for software and services on the Internet. As long as you adhere to some technical standards to ensure interoperability, you can innovate.

Excessive concentration of control is obviously BAD

As a few enormous companies control more resources and critical services on the Internet, they are becoming, effectively, dictators. For example, it is difficult to have a successful website today without adhering to Google’s guidelines, because if you don’t, your site won’t be ‘findable’ via Google search. It is difficult to criticize the business motive to grow and provide a very appealing service, even though the end result may have a monopolistic impact. Even though you may regard these ’technology dictators’ as benevolent, that doesn’t change the fact that they have excessive control.

Large scale web hosting is a natural monopoly

A lot of network services are natural monopolies - there are such advantages that come with massive scale that it is very hard for any new entrant to compete effectively with a larger, established system. This is why common carriers are generally regulated industries, because they are natural monopolies in the geographies they serve. However, the big web-hosting providers are also natural monopolies, and they are unregulated. Enterprise networks and service provider access networks are actually becoming natural bastions of local control, slowing the inexorable increase of centralization on the Internet. Widespread deployment of DoH will weaken those independent network domains and further contribute to the hegemony of CDNs and centralized hosted service providers. While there may be some efficiencies and optimizations possible with greater centralization, history and experience has shown again and again that eventually we will regret relinquishing control to a few unregulated, self-interested giant tech companies. Eventually, this loss of independence and self-determination will lead to less freedom of choice, less competition, and less privacy and security.

Why is ISC implementing DoH?

So, if we are so skeptical of DoH in its current state, why has ISC committed to implementing DoH in BIND 9? The development of encrypted DNS is something we welcome, in general. We are also not in the business of policing the Internet. We have tried, in a few cases, to police what we regard as anti-social behavior by refusing to tolerate some violations of Internet technical standards. However, DoH is being standardized in the IETF, and we want BIND 9 to be a reference implementation of the standards. ISC exists to help users of our software make the most of critical Internet services. Some of our users now want to at least experiment with DoH. There are efforts underway to fix the biggest problem with DoH, which is the lack of mechanisms to configure the client. Also, Mozilla, one of the big proponents of DoH and user privacy in general, has graciously offered to underwrite the development of DoH in BIND 9 so our users and support customers don’t have to fund it. It is possible that DoH will turn out to be a good thing in the long run. In any case, we are going to enable people to try it, to experiment with it, and to evaluate the likely impact.

What can you do today?

For accurate technical information on the characteristics and status of both DoH and DoT, we recommend the dnsprivacy.org web site. If you are an enterprise concerned about users bypassing your network security, you probably need to develop a policy, and you may wish to attempt to block DoH. Mozilla is helpfully providing a mechanism to enable network administrators to block Firefox users from using DoH if there is an incumbent DNS resolver.

Most ISPs and enterprises that want to be on the leading edge of DNS privacy might want to start experimenting with encrypted DNS and offering DoH alongside regular DNS. It is possible today to deploy encrypted services today using BIND 9 with an HTTP proxy, such as NGINX, HAproxy, or a DNS-specific proxy like this one from the author of DNScrypt or DNSDist from PowerDNS. ISC is committed to producing versions of BIND 9 in 2020 with the proxy function better integrated to facilitate a quality service deployment. We will also, at the same time, work on DNS over TLS, which is a competing DNS encryption method that does not transfer control of the DNS to the big web server providers. DNS over TLS is evolving much more slowly, however, because the major desktop operating systems don’t yet support it. There is a group of implementers forming to exchange information about how to deploy DNS encryption, and researchers are starting to publish studies on the impact of encryption on DNS latency and scalability.

To learn more about how DoH compares to DoT, or how to deploy or block DoH today, listen to our webinar on the topic, scheduled for December 11, 2019.

Here are links to some essential reading on encrypted DNS

  • [Encrypted DNS dot org](https://www.encrypted-dns.org) - and check out the [active mailing list archives](http://bit.ly/EDDI-List-Archives)
  • [DNS Privacy dot org](https://dnsprivacy.org/wiki/) - https://dnsprivacy.org/wiki/ is an excellent, authoritative resource on the different DNS privacy solutions and how they compare.
  • [M3AAWG tutorial on encrypted DNS](http://www.m3aawg.org/dns-crypto-tutorial) - www.m3aawg.org/dns-crypto-tutorial provides detailed instructions on how to deploy encrypted DNS.
  • [Excellent summary of one enterprise's choice wrt the DoH/Firefox controversy](https://www.dns.cam.ac.uk/news/2019-09-19-dont-use-application-dns.html), as of September 2019 - from Tony Finch of Cambridge University, https://www.dns.cam.ac.uk/news/2019-09-19-dont-use-application-dns.html
  • [Sam Knows on DoH performance](https://www.samknows.com/blog/dns-over-https-performance) - https://www.samknows.com/blog/dns-over-https-performance
  • [List of publicly-accessible DoH servers](https://github.com/curl/curl/wiki/DNS-over-HTTPS) actively maintained by the community - https://github.com/curl/curl/wiki/DNS-over-HTTPS
  • [Mozilla canary domain](https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet) - a tool for blocking DoH, https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet
  • [Centralized DoH is bad for privacy](https://labs.ripe.net/Members/bert_hubert/centralised-doh-is-bad-for-privacy-in-2019-and-beyond) - RIPE NCC Blog by Bert Hubert, https://labs.ripe.net/Members/bert_hubert/centralised-doh-is-bad-for-privacy-in-2019-and-beyond
  • Is New always better? [UDP vs Doh](https://blog.apnic.net/2019/12/06/is-new-always-better-udp-vs-doh) - APNIC blog from University of London, https://blog.apnic.net/2019/12/06/is-new-always-better-udp-vs-doh/
  • [DoH: Anti-competitive and Network Neutrality Aspects](https://blog.powerdns.com/2019/12/03/doh-anti-competitive-and-network-neutrality-aspects/) - PowerDNS Blog by Bert Hubert, https://blog.powerdns.com/2019/12/03/doh-anti-competitive-and-network-neutrality-aspects/
  • Blog from Bluecat Networks "[DNS over HTTPS: What, Why, & Who Cares](https://www.bluecatnetworks.com/blog/dns-over-https-what-why-who-cares/)"
  • [DNS Security: Threat Modeling DNSSEC, DoT, and DoH](https://www.netmeister.org/blog/doh-dot-dnssec.html) - https://www.netmeister.org/blog/doh-dot-dnssec.html
  • [RFC 8484 (DoH)](https://tools.ietf.org/html/rfc8484) & [RFC 8310 (DoT)](https://tools.ietf.org/html/rfc8310) - the IETF technical standards documents
  • [Signaling That an Authoritative DNS server offers DoT](https://datatracker.ietf.org/doc/draft-levine-dprive-signal/) (new proposal that would help networks deploy DoH alongside ‘regular’ DNS)

Recent Posts

What's New from ISC