Opinions divided on encrypted dns queries
Dns is also called ‘the last unencrypted mile’ of the internet: the last step in the route that an internet package takes before it presents a website. Exactly this last bit is sent completely in plaintext. The reason for this is that the encryption of DNS requests can cause more problems than you might think.
You would almost forget it, but there was a time when we sent all our WhatsApp messages over an unencrypted connection, where everyone who was in between the sender and receiver could just read what you wrote. Only six months after the Facebook acquisition, WhatsApp included end-to-end encryption to the app. Before that, all those millions of messages were passed through the ether in plain text, readable by everyone.
A lot has changed since 2014. Whereas it was still completely normal to chat and browse unencrypted, the trend has now gone radically the other way. If you release a chat app in the year 2019 without encryption, you can count on little sympathy from endusers, and with Let’s Encrypt you can even give the most ridiculous blog a green lock. Meanwhile, browsers such as Chrome, Firefox and Edge also display prominently when a website is not encrypted.
Encryption now appears to be the standard, but that does not mean that all internet traffic is already encrypted. Or at least, the entire process of an internet connection. There are, after all, a few loose ends that are executed without encryption and that means that they can easily be tapped or monitored.
Dns traffic is still unencrypted
One such loose end is the connection to a DNS server. This process of looking up the domain name that belongs to an IP address is still happening unencrypted, not surprising for a protocol that has existed since 1983 and has not had much reason to change so far. Not encrypting something has disadvantages, as you expect. This is because it makes it relatively easy for an internet provider to find out which websites someone visits or who visited a certain website. That is why browser developers are working on a new protocol:
dns-over-https, which also encrypts that last bit of traffic.
At first glance Dns-over-https seems to have many advantages. Encryption of internet traffic is always an improvement, because as an internet user you remain anonymous for more parties. Nevertheless, the implementation of the protocol has led to strong discussions in recent months. Dns-over-https has supporters and opponents, who find the protocol very good or not good at all.
What is dns-over-https?
DNS, or domain name system, is the protocol that translates domain names into the corresponding IP addresses. Handy, because as a user you don’t have to remember sny IP addresses. A DNS request is made at a DNS resolver, and this is where the bottleneck is. The communication between the resolver and the applicant is not encrypted. Anyone who gets caught up in the middle can check from which IP addresses a certain website is requested, or vice versa: which websites are requested from a certain IP address. Parties in between are not necessarily hackers with complicated man-in-the-middle attacks, but also providers.
dns-over-https establishes an encrypted connection between those parties with a SSL or TLS encryption, so that the provider can no longer read what you are doing, and neither can the hacker with his MIT attack.
Dns-over-https, also known as DoH for short, is on the rise. Driving forces are browser developers Google and Mozilla. Both are experimenting with the possibilities to implement the function in their software. Or rather, to enable DOH as standard, because it was possible for a long time to send the dns traffic over an https connection. The setting was always somewhat hidden in Firefox, but users who wanted to use a specific DNS resolver such as CloudFlare or Google could simply do so.
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 18.104.22.168 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.
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
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.
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.
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.
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.
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.
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.
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.