Dns-over-https: curse or blessing?

Both dns and https are existing standards, but the combination has only been established as an official standard for a year. IETF, the body that regulates internet standards, set RFC 8484 as the standard that software developers should use. Since then, Mozilla and Google have been experimenting with DOH in their browsers. Operating systems do not yet support the protocol natively.

In the dns-over-https testing phase, implementation was done with careful steps: slowly, and above all with opt-in. Those tests also started relatively recently; Mozilla added DOH to Firefox in June 2018 as an experimental feature. Chrome only added it in May of this year. However, the developments went fast and now both Chrome and Firefox have concrete plans to have DoH enabled as standard.

However, the implementation of DoH differs between the two browsers. Mozilla opted for collaboration with Cloudflare. The function becomes opt-out. The traffic of a user who does not change anything will henceforth run via the 1.1.1.1 DNS resolver of the American company as standard. This will only happen for a limited number of users and only in the United States.

Thanks in part to the speed with which Firefox is now picking up DoH, Google is also accelerating the rollout. In Chrome 78 a test is done in which DoH is automatically switched on if certain criteria are met. When a user visits a site, Chrome checks whether the currently set dns provider is in a whitelist. In addition to Google’s own DNS resolver, it also includes Cloudflare, Cleanbrowsing, Quad9, OpenDNS and DNS.SB. If the dns provider is not in that list, for example if a user is on a corporate network, Chrome will automatically use that standard resolver. The function also becomes opt-out; users who do not want to participate in the experiment can change their settings via chrome: // flags / # dns-over-https.

Privacy

Dns-over-https is marketed as a privacy protection measure. Not entirely illogical; the current dns protocol is pretty much one of the few remaining internet structures where encryption is not yet the standard. Google and Mozilla naturally also say that they consider privacy to be highly important and introduce the entire DoH protocol to ensure user privacy. Cloudflare is also firmly committed to this; the company markets privacy as an important feature.

“DNS-over-https is a good thing for US internet users in particular” On the one hand, it seems strange that DNS is another archaic protocol without much change. Now that most internet protocols, apps, websites and services are increasingly using encryption, dns seems a bit old-fashioned because it is the only protocol that remains behind. On the other hand, you may wonder what exactly dns-over-https solves. For example, does the protocol really make you anonymous? Experts doubt that. The idea of ​​encrypted DNS requests is that providers cannot watch who makes such a request. However, arguments change and DoH does not encrypt data that cannot be intercepted by a provider in countless other ways. For example, there are still plenty of websites without https or at least pages with http elements on them. There are also other protocols, such as sni or ocsp, from which internet service providers can retrieve a lot of information related to the origin of the traffic.

The fight around DoH started at large tech companies for which America is the most important market. The differences in internet culture between America and Europe also distort the discussion. In the EU, ISPs are comparable to a type of utility. They are relatively neutral and mainly transmit internet traffic from A to B. In America that is different; providers make a lot of money there from the browsing history of customers. For an American internet user it is therefore a lot more attractive to send the dns traffic over https.

Dns-over-tls

At first glance, it seems like a good idea to encrypt dns requests. In the meantime, however, the question arises as to whether https is the right method for this. This is because it has some disadvantages, such as centralization, which results in a single point of failure, but it is also important that dns is used for network protection and monitoring. Such functions disappear when the queries run over DoH.

Cloudflare requirements

You may not find it desirable for providers to sniff your internet traffic, but the reality is that they have their responsibilities. In the EU, for example, providers must scan websites for undesirable content: think of terrorism or child pornography. And then of course there is the notorious Pirate Bay blockade. With dns-over-https it becomes much harder for internet providers to introduce such blockages. That does not mean that The Pirate Bay will be immediately accessible again. It is still possible to block an IP, for example, but a court order for a block can now also go directly to CloudFlare or Google.

An additional effect of this is that really only large dns providers can use Google or Mozilla. Smaller providers, such as the Dutch PowerDNS, cannot meet the requirements set by those companies. “Mozilla, for example, makes heavy demands,” according to PowerDNS founder Bert Hubert: “We have tried it together with partners, because without a global network you cannot participate. You must also report any legal requests to Mozilla that comes in, which is not allowed at all.”

Https is not the only way to encrypt traffic. Experts are increasingly voting not to encrypt dns via https, but with tls. DoT is a layer on top of standard dns, instead of having to create a whole new zipper of dns resolvers. With DoT it is also easier to perform packet inspection and thus scan for malware or unauthorized content on a network.

One single port

However, this process also has its drawbacks. DNS-over-https traffic passes through port 443, the port through which all other https traffic passes. Providers, authoritarian governments or anyone else cannot just switch off that port to disrupt a process. After all, the majority of the internet would then be blocked.

With dns-over-tls it is different. This runs through the unique port 853. It is therefore a lot easier to block it in one go. Due to strict net neutrality rules, this will not happen so quickly in the EU, but for other countries DoT is therefore a potential bottleneck. Providers who still want to see DNS requests can therefore more easily prevent this. Certainly in the early stage of the discussion about encrypted dns requests, many were still against dns-over-tls for this reason. As a result, most software makers preferred dns-over-https. In the meantime, experts seem to be divided about which method is the best and which disadvantages outweigh the advantages.

Criticism and regulation

Privacy and encryption: it sounds nice, that anonymity, but there are also disadvantages. Dns-over-https, for example, can cause problems for many companies that have their own corporate networks. In addition, the dns protocol helps users by connecting to the nearest or at least the fastest server in the area. With dns-over-https, that also becomes a lot harder.

Corporate networks

A lot of criticism of dns-over-https comes from the businesses. Many companies use their own DNS resolver, for example, to set up content blocks. If a company sets up a VPN, it automatically gets its own name server. In such cases, dns-over-https is not the answer, on the contrary. Using DoH, centralized dns institutions can be bypassed and employees can easily avoid such blockages. Then there is the fact that dns queries are often used to scan for malware. If those are encrypted by default, system security officers have a problem.

This gives them a few options, none of which are ideal. Blocking Https traffic is not an option, so they must disable the DoH function that is now standard in browsers. This is not exactly ideal for a byod (bring your own device) environment. Ignoring browser version updates as a whole is an option, but not forever. For that reason, the implementation that Google has devised, with DoH only being implemented if there are no other settings above, is a reasonable middle way. If a company has its own resolver, it is not overwritten by the built-in DoH protocol.

Malware

Not only does dns over https make it harder to block malware, malware has already been spotted that is actually abusing the new protocol. In July, researchers at Qihoo 360 discovered that Godlua malware had been updated and abused dns-over-https to bypass malware scanners. The malware does this by encrypting dns queries to the command and control server, making it more difficult to spot. At present, not many such cases of malware are known. For this reason too, there are many security experts who argue for dns-over-tls instead of dns-over-https. The DoT protocol is, as stated earlier, much easier to block.

Above all practical objections there is a somewhat more abstract discussion about ethics and freedom. DNS is now still a largely decentralized protocol. However, encrypted dns connections run via a handful of large providers, with Google, Cloudflare and Quad9 at the forefront. With that, dns is becoming more and more centralized and you may wonder if that is a good thing. CloudFlare has clarified that it does not sell user data, but will it remain so now that the company is listed on the stock exchange? And even if the company continues to act ethically, a single point of failure is still not a good idea. Anyone who needs further proof for that, just look at the CloudFlare disruption of last July.

The concept of encryption has a good image for most users. Encryption suggests that nobody can read what you write. In the case of dns-over-https, however, it does not mean that your traffic will be completely anonymous. Your provider sees less, but the dns resolver, such as Google or Cloudflare, sees more. The problem is simply moved. Moreover, in such a case, DNS queries are placed with a commercial party, which is usually a lot less regulated than an internet service provider.

Government regulation

If you say encryption, there are always people who will prance. After all, the terrorists and child porn spreaders are hiding behind it and therefore encryption would be bad. This old argument also adds value in this discussion. Especially in the United Kingdom this was an important point in the discussion. ISPs have strict obligations there, such as the infamous porn filter (which is scheduled to be rescinded). Interest and human rights organizations are also afraid of the implications. In the UK, for example, the Internet Watch Foundation warned that dns-over-https would make “the fight against online child abuse” more difficult.

In the country, the discussion even flared up so much that the joint venture of internet providers, the Internet Service Providers Association, nominated Mozilla for the price of ‘internet villain’. Although the ISPA eventually withdrew the nomination, the lobby proved to be successful. Mozilla recently announced that it would not use dns-over-https in the UK.

Not entirely unexpectedly, the criticism also comes from commercial organisations. Not only British legislators and ISPs are dissatisfied with the plans, but there is also irritation in America. An interest group of major Internet providers in the US wrote a letter to politicians. They were afraid that the plans in particular would strengthen Google’s monopoly position. Also, DoH in Chrome would lead to ‘critical internet functions’ being disrupted, such as the aforementioned content blocking.

DoH is also under attack on a political level. Regulation is lurking. In the US congress, Google is now again under a magnifying glass due to concerns about unfair competition. The company would attract all internet traffic and fully consolidate the market.

Conclusion

You could say that dns-over-https is a good step for the privacy of the average internet user. Encrypting “the last bit” of an internet connection when it didn’t happen for years is good for consumers at first sight.

In the meantime, however, there seem to be a lot of trouble with the plan. Centralization of a traditionally decentralized protocol is an important objection, but more importantly, the implementation in particular leaves much to be desired. Internal corporate networks and security software can run into problems if the protocol becomes the standard, and you can wonder to what extent the technology really protects the user.