The IETF is in the midst of a vigorous debate about DNS over HTTP or DNS over HTTPS, abbreviated as DoH. How did we get there, and where do we go from here?

(This is somewhat simplified, but I think the essential chronology is right.)

Javascript code running in a web browser can’t do DNS lookups, other than with browser.dns.resolv() to fetch an A record, or implicitly by fetching a URL which looks up a DNS A or AAAA record for the domain in the URL.

It is my recollection that the initial impetus for DoH was to let Javascript do other kinds of DNS lookups, such as SRV or URI or NAPTR records which indirectly refer to URLs that the Javascript can fetch or TXT records for various kinds of security applications. (Publish a TXT record with a given string to prove you own a domain, for example.) The design of DoH is quite simple and well suited for this. The application takes the literal bits of the DNS request, and sends them as an HTTP query to a web server, in this case probably the same one that the Javascript code came from. That server does the DNS query and sends the literal bits of answer as a DNS response. This usage was and remains largely uncontroversial.

About the same time someone observed that if the DoH requests used HTTPS rather than HTTP to wrap DNS requests, the same HTTPS security that prevents intermediate systems from snooping on web requests and responses would prevent snooping on DoH. This was an easy upgrade since browsers and web servers already know how to do HTTPS, so why not? Since DoH prevents snooping on the DNS requests, a browser could use it for all of its DNS requests to protect the A and AAAA requests as well, and send the requests to any DoH server they want, not just one provided by the local network.

This is where things get hairy. If the goal were just to prevent snooping, there is a service called DNS over TLS or DoT, which uses the same security layer that HTTPS uses, but without HTTP. A key difference is that even though snooping systems can’t tell what’s inside either a DoT or a DoH transaction, they can tell that DoT is DNS, while there’s no way to tell DoH from any other web request, unless it happens to be sent to a server that is known to do only DoH.

Mozilla did a small-scale experiment where the DNS requests for some of their beta users went to Cloudflare’s mozilla.cloudflare-dns.com DNS service, with an offhand comment that maybe they’d do it more widely later.

On the one hand, some people believe that the DNS service provided by their network censors material, either by government mandate or for the ISP’s own commercial purposes. If they use DoH, they can see stuff without being censored.

On the other hand, some people believe that the DNS service blocks access to harmful material, ranging from malware control hosts to intrusive ad networks (mine blocks those so my users see a blue box rather than the ad) to child pornography. If they use DoH, they can see stuff that they would rather not have seen. This is doubly true when the thing making the request is not a person, but malware secretly running on a user’s computer or phone, or an insecure IoT device.

The problem is that both of those are true, and there is a complete lack of agreement about which is more important, and even which is more common. While it is easy for a network to block traffic to off-network DNS or DoT servers, to make its users use its DNS or DoT servers, it is much harder to block traffic to DoH servers, at least without blocking traffic to a lot of web servers, too. This puts network operators in a tough spot, particularly ones that are required to block some material (notably child pornography) or business networks that want to limit the use of the networks unrelated to the business, or networks that just want to keep malware and broken IoT devices under some control.

At this point, the two sides are largely talking past each other, and I can’t predict how if at all, the situation will be resolved.