Why You Shouldn’t Rush Into DoH

While being a core component of the Internet, DNS remains one of the least secure protocols in active use. DNS security is a long-standing debate, with DNS privacy a much more recent matter and a source of division among the security community. Indeed, privacy matters and must weigh in the balance when considering DNS security. However, security is not only about confidentiality. Protocols such as DNS over TLS or DND over HTTPS must be leveraged wisely to strengthen network security, rather than introducing bias that could prove costly in the future. Movements are massive around DNS resolution at the application level, so it’s worth taking a step back to see the whole picture before moving in the wrong direction.

Let’s first consider the need. Why are we looking for both DNS privacy and security? There are two main reasons:

1. Legitimate domain owners expect that DNS answers sent from their Name Servers will be transmitted to the DNS clients without alteration so that the client accesses a genuine service – this is about integrity
2. DNS clients expect their privacy to be respected and that the DNS answers they receive are trustworthy – this is both about integrity and confidentiality

Why is it so challenging? First, because DNS was designed to permit resource delegation, maximizing service availability and performance when security was not yet a major concern. As a result, the Domain Name System ends up being a widely-distributed hierarchical database leveraging 3 different components:

• The authoritative Name Servers – The authority that holds actual DNS records for a domain
• The resolvers – The servers providing name resolution services for the clients on a network
• The clients – The various systems relying on DNS for reaching network services/content

What matters most regarding the security challenges previously mentioned are the resolvers. These components of the Domain Name System are the ones trusted by the clients, and therefore the most sensitive for numerous reasons:

• DNS traffic is not encrypted nor authenticated, a client connected to an unsecured network can be tricked into using any rogue DNS server. This was demonstrated in the “Breaking LTE” attack. Once the client uses such server, he can easily be directed to malicious content (even if SSL certificate validation offers additional protection, it’s not sufficient)
• The DNS resolver is part of the network infrastructure and acts as a cache for the DNS protocol. Therefore, it has extended visibility over network activity and can be used as a network security solution (detecting suspect behaviors), to protect both the clients (preventing them from accessing known malicious content) and a company’s assets. Most of the time, this DNS component is provided by the access network operator because many local network services depend on private DNS zones (e.g. an enterprise internal application or voicemail)
• The DNS resolver can enforce the use of security mechanisms such as DNSSEC (see What is DNSSEC) to validate the integrity of the answers stored in its cache before serving them to the clients, contributing to their safety

In the end, securing DNS is all about securing/trusting the resolution process. To do so, several options have been studied:

• Revising the operating system’s DNS lookup library to natively enforce DNSSEC validation and DNS traffic encryption could have been an option, but the maintainers have expressed scalability and security concerns on integrating cryptographic components to this critical operating system library.
• Relying on a local system daemon for DNS resolution process. For example, this process is the one currently leveraged to implement DNS over TLS in systemd or by Cisco for enforcing DNS protection on mobile clients with Umbrella. In this scenario, the local agent listens on the loopback and the libc point to this resolver, which enforces the use of security mechanisms such as DNSSEC and secure communication with the resolver using DNS over TLS or alternative protocol such as DNSCrypt or DoH. The only issues with this solution are slow deployment and maturity. For instance, until late June 2019, the system resolver was not validating the SSL certificate of the DNS server when using DNS over TLS.
• Deporting the DNS resolution into applications such as the browser. This option comes mainly from the initiative of some internet giants supporting DoH on behalf of privacy concerns. With this approach, each application embeds its own resolution mechanism independently of the Operating System. This allows to ignore current implementation and quickly move forward but comes with significant security and operational implications.

It’s too soon to tell which is the best option, but in each scenario, the client continues to rely on the external DNS resolver, mostly for scaling purposes. Therein lies the main security issue. As DNS is part of the network infrastructure, it’s commonly leveraged for various purposes (legitimate or not). According to best practices, connected clients should only be allowed to reach the local network’s DNS resolver. That way, DNS can be used to prevent phishing, malware spread and detect malicious behavior (network scan, exfiltration, etc.) as part of enterprise network security strategy.

This is often achieved in two ways, either using Deep Packet Inspection (DPI) at the firewall level or at the DNS resolver level using a DNS firewall. Obviously, encryption will forbid DPI analysis. But it can also allow a client to bypass the local DNS resolver if the ciphered traffic cannot be identified and blocked. Clients can then use any external DNS provider, with all the security concerns this can raise. In this context, DNS over TLS is not seen as a threat, whereas DoH is. The reason is pretty simple: DNS over TLS relies on a dedicated TCP port (853) and can be easily filtered on a network’s boundary. DoH, however, relies on the infamous https port 443. This prevents any attempt to filter related traffic, effectively making it a wide-open door to the internet from any secured network.

Worse, while the claim to protect internet users’ privacy is legitimate, we can seriously question the intentions of the tech giants supporting DoH, as they are for all intents and purposes insidiously centralizing all DNS queries for processing. Don’t be fooled- while the traffic between the clients and the service is encrypted, queries are performed unencrypted and the data will most certainly be processed for various, yet undisclosed, purposes. Remember the adage: if the service is free, then you are the product.

In the end, DoH is a nice try to address the DNS security challenges the DNS community has minimized for a while. Yet this attempt deliberately seems to ignore the security concerns of network operators and organizations and may dupe users through a false promise of privacy.

Current DoH deployment proposal means externalization of the DNS resolution. This implies loss of visibility over related network activity, weakening network security considering that 91% of malware are relying on DNS. It makes Internet slower as DNS resolutions will no longer fall below one millisecond, even with higher rate broadband networks. Finally, it generates new privacy issues. The question is, who is a better manager of your privacy- your own local DNS resolver or an external DNS resolver?

At EfficientIP, we do believe DNS traffic encryption is going to take off. DNS is hierarchical and somehow controlled by the root servers. This is legacy, yet it has been proven pretty efficient. However, it doesn’t mean the DNS can’t be enhanced. Technical solutions are already on the table. Network operators need to take back control over this too often forgotten protocol that is DNS. They must leverage trustable, distributed DNS services across their own network implementing DoT and/or DoH natively on their resolvers and support DNSSEC deployment so that they can protect both privacy and their users from the many threats spreading on the internet.

For sure, DoH providers will appear on the market in order to answer region or organization regulation, but the market cannot be in the hands of the few current ones. We need to look at DoH usage from different angles from the viewpoints of users in the enterprise or end users at home, from privacy concern at the hotel, airport or café or for mobile users of a corporation. Future DNS solutions will embrace all the transport means to adapt to all the usages, current implementation is still in its infancy. DOH has become a hot topic lately with browsers and ISPs. Mozilla has pushed the limits with its Firefox initiative and Cloudflare. Google plans on testing ISPs with it’s DNS over Https with Chrome.

For more information:

• DoH! To block or not to block?
• DNS over HTTPS (DoH) Considerations for Operator Networks
• An Analysis of Godlua Backdoor
• DoH Creates More Problems Than It Solves