|
Anyone that has attended a meeting of the Internet Engineering Task Force (IETF) will know that the somewhat dry topic of internet protocols is often the source of passionate disagreement. But rarely does that debate extend beyond the confines of internet engineers.
That has not been the case with a new protocol which aims to make the Internet’s underlying domain name system more secure by default. In recent months, the adoption of DoH, standing for “DNS over HTTPS” has become the subject of heated argument in both tech and mainstream newspapers, as well as the halls of power in both the US and UK.
“Google Draws House Antitrust Scrutiny of Internet Protocol,” reads one headline from the Wall Street Journal. The first paragraph of a different article from The Guardian reads: “The maker of the Firefox web browser has told the government it has no plans to turn a controversial web privacy tool on by default in the UK, despite launching it in the US later in September.”
In brief, internet giants Google, Mozilla and Cloudflare have been accused of a global internet power grab by the companies that connect everyone to the Internet—internet service providers (ISPs)—and in return, those companies have accused ISPs of trying to protect their turf at the expense of internet users’ privacy and security.
Meanwhile, some internet engineers warn that DoH is a threat not just to people’s privacy, but the stability of the Internet itself. And they have been met with counterclaims that they are out of touch and don’t grasp how the Internet actually works in 2019.
Internet protocols are never this controversial. So what’s behind the dispute, how much of it is true, and what do people responsible for large networks need to do about it? I spoke to those on both sides of the debate to find out.
The first thing to know about DoH is that people can’t even agree on how to refer to it. Some say it as a word—“dough”—others spell out the letters D-O-H and others insist on referring to it in its long form: DNS over HTTPS.
Marshall Erwin is Mozilla’s senior director of trust and security and a proponent of the “dough” school of pronunciation. From Mozilla’s perspective, the move to DoH is quite simple: it provides users with greater privacy and security.
“The internet’s business model is broken,” he told CircleID. “Websites engage in pervasive tracking and DoH safeguards users from that tracking; it protects them from ISPs that may try to collect and monetize user data.”
Erwin points out that in the US, ISPs specifically—and successfully—lobbied to be released from new rules that would have prevented them from selling or sharing user data and gives several examples where user data has already been monetized. He also notes that ISPs’ privacy policies are often “opaque.”
He is right that ISPs have been actively lobbying against DoH and not just in the US. In the UK, the ISP Association has also been very vocal in its opposition, but not, it claims, because it wants to gather and sell user data. Instead, it claims, DoH risks disrupting the Internet.
In a move that ISPA later backtracked on, it even nominated Mozilla for its own “internet villain of the year” award for its support of DoH. Adding the new protocol would “undermine choices that have been previously made by the user,” ISPA claimed, noting that parental filters could be ignored, enterprise DNS controls could be bypassed, and it would become harder to block illegal or damaging content.
In the US, ISPs went one step further, and in a letter to Congress, the three largest industry bodies, NCTA, CTIA and US Telecom, said that DoH “could interfere on a mass scale with critical internet functions, as well as raise data competition issues.”
That was a step too far for many. CTO of Cloudflare John Graham-Cumming, a company that is at the center of the DoH controversy as it is currently the default provider of DoH for Mozilla, told us he had “no idea” what American ISPs were referring to when they claimed “critical internet functions” would be affected.
Likewise, Bert Hubert, a veteran internet engineer and developer of widely used DNS software. Hubert and Graham-Cumming could not be more opposed on the issue of DoH, but they both agree that the NCTA letter was “terrible,” and Hubert says they are “not doing themselves any favors” by making such claims.
From Graham-Cumming’s perspective, the whole issue has blown up not because of the protocol itself but because it represents a fundamental shift in how people have previously understood the Internet to function.
The DNS—the system of users navigating the Internet by visiting specific websites—has always been controlled and overseen at the network level. But DoH moves that control to the application level. “People are not used to using the DNS like this,” he notes.
He doesn’t foresee this being a big problem, just a change. Network administrators are already used to introducing controls at the application level; DoH will just add DNS to the list. But both Cloudflare’s Graham-Cumming and Mozilla’s Erwin acknowledge that this is not going to be a simple or immediate change.
Mozilla says that of the criticisms levelled at it, the issue of parental controls and enterprise DNS being impacted are the most legitimate. Its solution, Erwin tells us, will be to watch for such controls and, if they are noticed, leave the DNS settings alone, i.e., not implement its DoH solution.
Graham-Cumming views it as more of a transition that companies will figure out in order to reap the security benefits of DoH. “There is already a lot of blurring between what is inside and outside the organization,” he notes, referencing Amazon’s ubiquitous AWS cloud service. Insisting that the DNS can only ever be a network-level consideration is “slightly old fashioned,” he argues.
Not so, argues Hubert. One of Hubert’s main fears is the same as Mozilla’s and Cloudflare’s—that people will figure out how to sell DNS traffic—but he fears that it will be Cloudflare that ends up doing so. It is a public company, he notes, and what it and its policies say now could well change in the future, especially if that traffic becomes increasingly valuable. The problem with DoH, he argues, is that it centralizes the control of DNS traffic now and in the future.
It is better to keep the DNS “technically neutral” rather than go down a route that looks appealing now but could cause all kinds of problems later. What DoH fundamentally appears to be trying to emulate, Hubert argues, is a VPN (virtual private network). But you can set up a VPN already without impacting the Internet’s underpinnings, whereas DoH brings with it a host of other changes.
With a more centralized DNS, the risk of a single point of failure increases. If Cloudflare system goes down—which it did just a few months ago—then huge numbers of people, millions of people, will effectively be taken offline. And, to make matters worse, it won’t be clear who’s to blame.
Of course, one solution would be for all ISPs to offer their own DoH service—that way, all DNS queries are encrypted, but ISPs will be able to see the traffic and act on it accordingly. It is not that expensive or technically difficult, claims Cloudflare’s Graham-Cumming and some ISPs are already considering doing exactly that.
Google’s DoH approach in its Chrome browser will help that shift: it will first check if the DNS service you are using allows for DoH and stick with it if it does. If it doesn’t, it will shift to one that does.
Mozilla has gone for a different approach: you will, in the future, be able to select your default DNS provider in a similar way that you can choose your search engine provider now. But to get on that list, Mozilla says it will require companies to agree to delete such data within 24 hours and promise not to sell it.
Either way, DoH represents a clear shift in power away from ISPs and toward browser makers and that makes ISPs uneasy, especially given what has resulted from more centralized power in other parts of the Internet: Google is under investigation across the globe for abusing its search engine domination; and Facebook’s virtual control of social media has led to widespread and well-documented abuses of data.
One man who has a broader perspective is the executive director of the London Internet Exchange (LINX), Malcolm Hutty. “Both sides have legitimate points,” he notes. “ISPs want to do blocking to protect against unsavoury content, and DoH will make it harder for them. Mozilla and others want DoH to protect users and provide greater cybersecurity. At the end of the day, both of them are tampering with the DNS but for a responsible purpose.”
As to what those in charge of large networks should do, the answer, right now, is to watch and wait. The good news is that everyone agrees with the overall goal of DoH: encryption of DNS queries. Whether it becomes the de facto standard, or an alternative in the form of DNS-over-TLS (DoT) does, or whether a new standard appears, it is impossible to know.
Either way, all those engaged in the fight recognize that any solution that does not allow enterprises to decide for themselves how to run their networks is not going to be acceptable.
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byRadix
Sponsored byCSC
Sponsored byVerisign
Sponsored byDNIB.com
For me the big technical problem with DoH isn’t the protocol itself but that it breaks the assumption that name resolution is consistent: it doesn’t matter what on the machine asks the question, the answer will be the same. By moving resolution into the client it’s no longer possible to assume that just because application A resolved a hostname one way that application B will resolve it the same way. That’s going to create any number of headaches we’d be better off not having.
DoH also, I think, tries to solve the wrong problem. Applications ask the local resolver, that connection’s secure because it’s just between two processes on the same machine. The local resolver usually queries the local network’s recursive resolver, usually the DNS server on the local router if you’re talking about a home network. For enterprise networks it’ll be the DNS servers set up by the netadmins. In either case the DNS traffic between hosts and the recursive resolver’s all happening over local switched Ethernet or the equivalent and snooping on it’s extremely difficult at best. Unless you’re deliberately trying to bypass your own network administrators, the main need for encryption is between the recursive resolver and the rest of the DNS system. Implement DoH or DoTLS there, that solves 90% of the problem. Implement it between the host resolvers and the local recursive resolver, that’s most of the remainder. All without breaking consistency.
And honestly I don’t see the big gain in DoH over DoTLS. DoH will _already_ be running over a TLS channel, that’s what provides the encryption for the HTTPS protocol, so all the HTTP part is doing is adding overhead. DoTLS takes advantage of the fact that TCP as a transport’s already part of DNS, and making anything that can talk TCP attempt to negotiate TLS and drop back to plain TCP if it fails is something we’ve been doing for decades. The fun part would be implementing TLS over UDP. Not that I’m crazy enough to undertake the project myself, but I’m pretty sure it could be done and I’m interested in hearing about the results of someone else’s attempt.
i agree with todd knarr above. see also this article.
"And honestly I don't see the big gain in DoH over DoTLS." In the context of your paragraph, the big "gain", as advertised by proponents, is that DoH is port 443 and as such can not be easily filtered in fear of breaking all HTTPS access, people will need to filter at the IP level (or other more elaborate mechanisms that have their own drawbacks), while DoT is on its own port, and as such can be easily filtered, just by triggering on the port. Of course, technically, each could run on any other port number, but that hinders automatic discovery (and standard DNS does not run in the wild on anything else than port 53 either). "The fun part would be implementing TLS over UDP." Too late, it exists already, this is called Quic (it has basically the useful features of TLS and UDP). And yes, DNS on top of Quic is already being drafted: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
I don't see use of port 443 as a gain, rather a downside. The standard protocols should _not_ be designed to bypass the network administrators. I can see many good reasons to block DNS resolution via off-network servers, eg. insuring that DNS resolves correctly for the local network when the on-network view of some zones differs from the off-network view (eg. any home network where local machines are automatically added to the zone while they're unknown outside the network, or any enterprise network where machines resolve to local addresses on-network but to gateway addresses or not at all off-network). Bypass of the local network policy should instead be the province of VPNs or other specifically-designed software, so that among other things admins don't _need_ to implement things that try to MiTM TLS on port 443 merely to insure that machines on their network receive the correct answers to DNS queries. Yes users can always install DoH on their own machines to try to bypass network policy, just like they can install VPN software to do the same. As with VPN software, admins can address it without having to try to separate out and not impact normal DNS traffic at the same time. They may have to disrupt normal Web traffic for machines using DoH software, but but the disruption can be limited to those machines rather than being necessary for all policy-compliant machines. And I simply don't care for the attitude of treating HTTP/HTTPS as a replacement for TCP. The more we do it the more fragile things become and that's never a good thing.
"I don't see use of port 443 as a gain, rather a downside. [..] And I simply don't care for the attitude of treating HTTP/HTTPS as a replacement for TCP. " Maybe, but proponents of DoH see it as a gain. The debate on how bad it is to have all Internet now running over HTTP(S) instead of TCP/IP (until QUIC maybe?) is an old one, and a lost one already. Many protocols use HTTPS exactly to not be hindered by various network rules, as 443 is almost never filtered. I am not saying any of this is good (or bad), just stating the facts.
I would dispute port 443. I haven't seen an enterprise network yet that didn't heavily filter ports 80/443, usually using methods that involve MiTMing TLS which causes innumerable problems with software (eg. you can't use the Microsoft-supported method of installing the Azure CLI on Macs with many enterprise security systems because the TLS library sees the MiTM and rejects the connection as compromised). Running DNS through this minefield seems at best imprudent, at worse a recipe for nightmares. And much of the complexity of the filtering, and the fragility it introduces, is directly _because_ so many protocols attempt to tunnel over 80/443.