DNS over HTTPS and DNS over TLS: understanding the associated security, visibility, and internet freedom implications
As more service providers and enterprises seek to address DNS-related security vulnerabilities, the debate between how to encrypt DNS traffic – and the consequential security implications of different encryption methods – is gaining traction. Primarily, the debate is between two standardized encryption approaches: DNS over HTTPS (DoH) and DNS over TLS (DoT). NetSTAR is keenly aware of the security implications of these two approaches.
Traditional DNS queries, sent over UDP or TCP, are in plaintext (without encryption) from a client to a DNS server. Often these queries use the default DNS settings of the local OS received, from the network provider – most of the time an ISP. But plaintext communication can be hacked, and can lead to spoofing or other malicious DNS-based activity.
To encrypt DNS traffic, DoH uses HTTPS and HTTP/2 to make connections over port 443. DoT uses TCP as the basic connection protocol with TLS layered over it for encryption and authentication via port 853. Port 853 is dedicated to DoT, whereas DoH uses port 443 along with all other HTTPS queries, meaning the DNS queries are “hidden” inside a larger volume of HTTPS traffic.
DNS over HTTPS
The DNS over HTTPS standard is defined in RFC 8484. Put simply, DoH encrypts DNS queries and disguises them as regular HTTPS traffic across port 443. These DNS queries are sent to DoH-capable DNS servers, or resolvers. And that is a major talking point for those who advocate online privacy. Due to the encryption, DoH supposedly prevents ISPs from tracking user traffic.
In fact, many DoH advocates argue that DoH can be used to bypass censorship in oppressed countries.
According to Freedom House, less than one quarter of the world’s internet users live in a country where the internet is designated as “free” in terms of rights and liberties (not pricing). DoH allows users in those countries to access a specific site which may be censored or outlawed by local government. Hence, for some, the DoH vs. DoT issue includes a human rights aspect, and they argue that DoH is the best way to support users in such countries gaining access to certain sites without government- or judicially-related consequences.
However, some argue that it’s irresponsible to advocate DoH for such users, as DoH only hides DNS traffic but not all other online activity and thus doesn’t prevent ISP tracking. One expert compares DoH to a “very partial VPN” that only encrypts DNS packets but leaves all other packets unmodified. So, if a website loads via HTTP, or if an IP address hosts a single domain, or because the ISP knows the IP address of the final destination website – any of these can help the ISP track online user activity. In fact, research by the University of Illinois showed that 3rd parties can identify, with 95% accuracy, to which websites users are connecting just by looking at the IP and by searching for Page Load Fingerprints.
From a security perspective, this is where one key difference resides. Even though an HTTP request is protected, the TLS handshake to set up encryption is not. The HTTP hostname is not available until the TLS handshake completes, but the handshake needs to provide the certificate for that specific hostname. Browsers provide the hostname twice, and the first time is in the clear, to allow the server to choose the correct certificate. This process is called Server Name Indication (SNI). Because the desired hostname is not encrypted, eavesdroppers can learn of the site visit request. Some governments use this exposure to implement censorship.
Beyond the issue that DoH likely does not hide user activity from ISPs, many security experts are not in favor of DoH for two other reasons:
- Encryption of the DNS protocol blocks organizations’ visibility into user attempts to access malware or harmful domains.
- For enterprises, local DNS servers and DNS-based software is used to filter and monitor traffic. But DoH bypasses enterprise policies by allowing users to overwrite DNS settings imposed centrally, and use DoH to avoid all DNS-based traffic filtering. This makes operating systems susceptible to DNS hijack attacks.
DoH is supported on Android, Mozilla Firefox, Google Chrome. These players are arguing for user privacy rather than for provider or enterprise visibility into DNS traffic across the network.
Mozilla has not only implemented DoH, but now encourages all its users to turn on DoH for their “privacy and security.”
DNS over TLS
Similar to DoH, DoT also allows DNS queries over an encrypted connection. Connecting over port 853, clients and servers negotiate a TLS session to secure the channel.
DoT has some disadvantages. Specifically, it only addresses encryption on a system resolver level, and it only works on one port. To shut down DoT, a malicious actor need only target the traffic between the resolver and the nameservers, or block port 853.
But many security professionals prefer DoT, since it will work on top of the existing DNS infrastructure and not require the creation of a separate class of DoH-capable resolvers. They argue for using DoT to encrypt the DNS connection outright, rather than hide DNS traffic inside HTTPS. Plus, TLS 1.3 supports encrypted SNI, something DoH does not.
Paul Vixie made the following comment:
“DoH is an over-the-top bypass of enterprise and other private networks. But DNS is part of the control plane, and network operators must be able to monitor and filter it. Use DoT, never DoH.”
And in response, Richard Bejtlich wrote:
“DoH is an unfortunate answer to a complicated problem. I personally prefer DoT. Putting an OS-level function like name resolution in the hands of an application via DoH is a bad idea.”
DoT allows network operators and security teams the ability to monitor DNS traffic as a separate communication stream from other HTTPS traffic. And therefore it avoids the scenario of having users leveraging DoH bypass in-place security measures to visit malicious sites.
A final DoT aspect for consideration is that cloud-based networking solution developers are more likely to employ DoH, as it allows for more flexibility through use of the existing HTTPS ecosystem.
At NetSTAR, we’ve seen steady growth in the number of DoH-enabled resolvers, and have added a category for DoH. That category will be available to all of our inCompass partners globally in Q1 of 2020.
The discussion around securing DNS continues. We’re staying engaged in that discussion with thought leaders and major industry members. We will enhance our capabilities according to partner demands and also based on our expertise concerning where the industry is headed.