|
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.
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byCSC
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byDNIB.com
Thanks for a concise summary, John, and it may be interesting to revisit this after the next IETF. One missing bit might be the potential side effects resulting from browser/app over-ride of network-assigned DNS servers. Given the share of some of those platforms, this could have the effect of dramatic centralization/consolidation of DNS resolution. While in some respects this might be good, there are also potential downsides that are worthy of consideration as well, such as to security, privacy, and stability/resiliency. I tried to touch on some of those issues in https://datatracker.ietf.org/doc/draft-livingood-doh-implementation-risks-issues/. Bottom line I think is that DoH and DoT can be really useful, but a lot will depend upon how they are deployed/implemented.
Yes, that’s also a good point. I gather that 8.8.8.8 already has a remarkably high share of DNS resolutions in the US so maybe that horse already left the barn.
John I believe you are referring to “browser.dns.resolve()” which is only supported by Firefox 60+ and only for browser extensions (not developers of webpages) https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve
There is no support from any browser vendor for JavaScript on a webpage to execute dns.resolve() or resolv()
That said the biggest concern I have with DNS over HTTP is that HTTP is much slower, by design, than current DNS protocol which defaults to UDP specifically for speed. Matter of fact TCP slows HTTP so much that google came up with QUIC that is the next HTTP 3 draft proposal.
If HTTP is moving from TCP to UDP for sake of speed why try and move DNS to HTTP, why don’t we just stick with DNS over UDP and add that TLS layer on it if that’s what we need. It might be a lot less work to upgrade all the DNS resolvers and all operating systems of all devices in the world to add TLS for DNS queries, and keep the backward compatibility for the users going through old systems. And let’s remember most important thing about DNS queries - most DNS resolutions are not done by apps written in JavaScript, rather apps running directly on OS using C, C++, C#, COCOA, or what ever client side application code - which all rely on the OS native DNS resolution methods underneath all the layers of frameworks and libraries.