DNS over HTTPS (DoH) is already here: the controversy is served

DoH (DNS over HTTPS) is really simple. Instead of going to port 53 of a server (for instance, the well-known 8.8.8.8) and asking for a domain through an UDP or TCP packet, DoH standardizes the construction of a GET or POST to a HTTPS domain, so the answer will be the A and AAAA records (the RFC doesn’t specify other records) with the IP. It has more details, such as the clever solution of turning the heading cache-control into the TTL. Everything encrypted carefully, of course. Do you remember when in a hotel you could tunnel the HTTP browsing via the DNS protocol (often unrestricted) to avoid paying the Wi-Fi? So now it’s the other way around.

By the way, there are also DNS over DTLS, DNS over QUIC, DNS over TOR… even a DoH that returns a Json, but this is a special adaptation used by Google (also by Cloudfare) more powerful (since, for example, it allows to check other records different from A
or AAAA).

Browsers are happy implementing it. It’s their opportunity to be powerful, not just because they already know this technology HTTPS, but also because it allows them to implement the resolver to be queried by default within the browser… For instance, Google could not access to  whatever is resolved through its famous 8.8.8.8, but it would extend its percentage of DNS’ users (around 13 %) to everyone using Google Chrome, 60 % now. It has been named “secure DNS”. They have seen the opportunity to break out of the system DNS exactly through the point where most domains are resolved: the browser. Google is already using DoH on Intra (released by Jigsaw Operations), which precisely is used to elude DNS blocks.

As for Android, it implements DNS over TLS on its last release, although it has not spread it so much. Currently, Cloudfare has also entered in the DNS business, so the 1.1.1.1 company is working with Firefox to provide reliable resolve. In fact, in Firefox DoH is known as TRR (Trusted Recursive Resolver). It promises not to use the bunch of users’ data that it may need. For example, Cloudfare is engaged to remove that sending of the 3 first octets used in a DNS query. This sending is a movement (with RFC) promoted by Google and OpenDNS in 2011 to improve DNS performance through IP location.

Moreover, another serious problem from TLS is the use of false certificates within the server, since they enable encryption breaking and spying. This bad practice is accessible for governments and, paradoxically, also constitutes a weak point of DoH derived from using TLS, especially when DoH has been designed specifically to ensure that governments can’t limit Internet through the traditional DNS. Any government could intervene only by using a false certificate also in the DoH (as sometimes done for other web pages).
Although DoT requires pinning use on its RFC, in DoH it’s not even recommended… Didn’t they plan to do it?

DoH is simply a new way to use DNS, and behind it the server queried can do whatever it wants (something that it already does) and it will actually do the same as any network resolver. The protocol itself does not change, what is modified is: How to access it and Who can get such access. The encryption regarding DoT does not change either, but now such encryption is done through a port 443, that hides the remainder of the encrypted traffic and then the DNS resolving is lost within the rest of queries. Just as the malware learnt (to neutralize firewalls’ reputation) to locate the server outside the network (instead of turning the victim into a server by opening a port); just as it understood later it was better to stop using strange ports (for instance, IRC) and communicating via the port 80, or later even via the 334. Just in the same way as we have transferred our hard disk to the cloud, and every application to the browser: DNS joins this trend, so its traditional functioning is reconsidered. All this raises doubts on how resolving will be set within the systems. Imagine that what was feared from governments could be done now by the applications developers or the major DNS owners, or on the contrary: in the future, maybe we will be able to download applications with their own DoH, and we will accept changes in the DNS queries only by accepting the terms and conditions –that nobody reads…

What about the power of filtering domains at the DNS level? It would not be possible with DoH, since the browser could keep visiting that phishing or command a control even if you have previously blocked it on the company DNS. Are we doing malwares a favour in exchange for user privacy and browser power?

However, DoH also opens new possibilities. For this to work, the multiplexed HTTP/2 is used, opening in turn other ways, due to the push that allows to resolve more domains in one go. Moreover, it allows to reduce the SNI leakage. Why? On HTTP/2, connections are reused. From the first connection to a site, the browser can know other sites hosted by this server and consequently reuse this connection for visiting. When connections are encrypted… Benefit is retaken from the channel without sending again the SNI. Since not lots of web pages are located in one server, this will happen most of the times.

In short: locally, pay attention to your browser and if you confirm something strange when resolving domains in your systems, you already know what may be happening; globally… we will see the new paradigms derived from this protocol.