Why Using DoH is Questionable

DoH (DNS over HTTPS) is an interesting solution for securing the transport of DNS traffic up to the first resolver. But is it required? What are the drawbacks? Do we really need it? Can we trust its usage and the DoH providers currently available? After a few months of intensive usage, some are pushing the message that in the context of an organization DoH is an important subject for I&O teams and more generally for the CISO & CIO to have a clear position and plan to manage its usage. As EfficientIP are experts on DNS Security, below are our thoughts on the DoH topic.

Securing DNS transport

One of the main ideas behind DoH is to increase the security of DNS and try to address privacy issues. It is true that from the early stages of the Internet, the DNS protocol has not been designed for data transport security. It has been designed for information storage and distribution efficiencies, service continuity, delegation of authority, and fast resolution of names (FQDN) to IP addresses. This model follows the architectural concept of loose coupling. Securing the transport through ciphering and the information through signature are new concerns that require specific answers.

Even though many solutions can be envisaged for bringing security to DNS, using known and robust ones is probably the most reasonable approach. Two main solutions are under implementation or deployment:

1. Improving the protocol by securing the transport and the information is a technical approach, mainly using DNS over TLS and DNSSEC,
2. Using DoH with global providers – but changing the philosophy of DNS has multiple repercussions going far beyond just technical aspects

Moving DNS resolution up to the application level

The push on the DoH solution is mainly being initiated by the application editors (e.g. internet browsers), relying on HTTPS as the transport. They have been long asking for the DNS normalization working group to progress on securing the way information is provided. Since no solution was proposed, they quickly implemented a solution to transport DNS payload on top of the HTTPS protocol and proposed to move the DNS process to the application layer, with the possibility of being directly hosted in the web application server. HTTPS is already mature, we know how to secure content and transactions through usage of digital certificates and public key cryptography. Implementing DNS resolution in the browser stack is not a big deal and, since it is not mandatory to use the operating system resolver, there are no technical issues for such an approach.

So DoH is moving the DNS resolution inside the application client code – in this case the browser or web app. Implementing DoH in legacy clients is a bit more complex but not impossible. Since most development frameworks propose a way to get content through transactions over HTTP, adding DNS resolution will not be overwhelming, and many implementations are already available on public code repo. As a consequence, any application could implement DoH to resolve FQDN to IP addresses using a specific DoH resolver. When implemented on the operating system side, the address for each DNS resolver were generally provided either by an automatic process like DHCP or directly in resolving configuration files with a good level of control by the organization’s I&O teams. With DoH, any application can use any DoH resolver available on the Internet. There is no automatic discovery or configuration process available at this time, but some providers are proposing easy ways to configure this through well known IP addresses (eg 1.1.1.1, 8.8.8.8 or 9.9.9.9).

Easy to use, easy to configure, secured… What’s the problem then with DoH?

In addition to being configurable by the application or the user, whenever a configuration interface is proposed, the DoH transport method is HTTPS and most of the time this protocol is free to go over the organization’s internal networks as well as over the Internet. HTTPS is ubiquitous. It can freely go through any firewall and security solution. It is seldom analyzed and can go end to end without any control. With TLS 1.3 and SNI encryption, it’s even more complex to just see which site is consulted in a session. If anyone wishes to block or control DNS traffic contained inside a DoH transaction, that would require deciphering of the traffic, which is only possible on Internet access point (e.g. internet proxy or firewall) and with the usage of a trusted certificate installed on the client operating system and applications. This requires the devices and their respective operating system to be under control of the organization (difficult with MacBooks, Linux, iPhones…).

DoH is moving the source of trust for DNS resolution. For good or bad reasons, DNS recursive (or forwarding) servers can filter requests and responses in order to provide safe browsing to their clients (e.g. filter malware, command and control servers or child sexual abuse content). In some organizations or governments, it can also be used to limit access to selected information, we all know that. Unfortunately, DoH usage suppresses the ability to filter and control. If the DoH server is not performing filtering with the same efficiency and following the organization’s policies, the client application is directly exposed, and therefore also its device.

When the DoH server is not part of the internal network and controlled by the organization, it has no knowledge of the internal domains used and so cannot resolve internal FQDNs. A fallback method is then required to switch back to a standard DNS resolver in order to perform internal resolution. Hence DoH does not suppress the need for recursive DNS servers. Going back and forth on DNS resolution for internal application names will impact user experience and complexify network troubleshooting when an application is not working as expected.

Using DoH with an external provider does not allow split DNS implementation that can offer different information for the same FQDN depending on the client location – from the internal network and from the external network. With DoH, everything is considered as external, meaning it’s not possible to direct internal users to a specific server for an application which is also exposed to the Internet. In addition, it is not possible to easily use GSLB on internal networks for multi cloud approach. And there is also a problem with reverse DNS resolutions that can expose the internal addressing IP plan to the external DoH provider, this could be very useful for an attacker who can use its DoH server embedded in the malware.

With regards to performance and user experience, managing DNS traffic over a TCP session (remember the ACK/SYN+ACK/ACK handshake?) with TLS security is dramatically complex. It takes time to establish a session and a lot of compute resources to perform the ciphering and deciphering of each request. In comparison, DNS in its standard unsecured flavor is reliant just on simple UDP frames.

Importantly, DoH still requires a DNS service to be operational over the network and the Internet. DoH is not replacing the hierarchical model, consisting of distributed information storage and authority. It is only securing the first hop of the communication between the application and the DNS resolver. In addition, as DoH uses an HTTPS session with only one configured endpoint, resiliency is more complex to perform because the DoH provider needs to set up either multiple servers in load balancing mode or in IP anycast. This represents a significant operational shift that could have an impact on the way the Internet is working. It will be more complex to troubleshoot, more open to malware attacks, less distributed and potentially controlled by just a handful of players. Since today only a few DoH providers are available, the model is generally described as “Centralized DoH”.

DNS and DoH resolvers are gathering a mine of useful information. As the first intent of most user traffic sits in DNS requests, the resolver has the ability to know what the user intends to do, what site he wants to visit. By moving the first resolver to an external corporation it also moves the information on all your application usages. If in the flow of a DNS request the application performs to the DoH provider, some are going to the same provider for application services (web hosting, mail, search engine, e-commerce, cdn, social media), then the traffic intent exposed by DoH can be directly linked to a user profile (up to the name, address, phone number, social security id, …). This can cause real data privacy issues, putting enterprises at risk.

Finally, though DoH is securing the first hop of the DNS transport, this does not imply “privacy”. For example, within the EU and under its GDPR act, users need to know when their data is transported, stored and manipulated if outside of the EU. How can a user know the service provider of DoH that is configured in the application he uses is compliant to such regulatory constraints?

Is DoH suitable for every usage?

DoH is not a bad technology and can bring solutions to very specific cases, mainly in the private scope and in some countries or cases where the DNS is not sufficiently reliable. For most organization usages it can be less than optimal: higher cost of problem resolution, no split DNS, no filtering, poorer user experience. Putting in place a specific DoH solution may help handle cases where organization users are directly connected to the Internet (roaming, home workers, …). But a nightmare scenario would be where applications include their own DoH server configuration without approval of the user and the enterprise. Malware could take benefit of such a scenario. As anticipated, we at EfficientIP have recently come across some concrete malicious usages of DoH, and they can be very scary.

See also:

• AdoptingEncrypted DNS in Enterprise Environments
• Centralized DNS over HTTPS (DoH) Implementation Issues and Risks
• DNS over HTTPS (DoH) Considerations for Operator Networks