Google Chrome / MS Edge

Google Chrome has offered DoH as an experimental option since version 78 (February 2018). The feature can easily be enabled in the GUI [9]. The latest version of the Microsoft Edge browser is based on Chrome, so Edge also supports DoH. The web browser contacts the DNS provider by DoH, which is configured as a classic DNS provider on the operating system side.

To do this, you call chrome://flags or edge://flags and enable Secure DNS lookups (Figure 6). As soon as one of the supported DNS servers is configured in the operating system (currently, the providers CleanBrowsing, Cloudflare, Comcast, DNS.SB, Google, OpenDNS, and Quad9 [10]), DoH is activated [11].

Figure 6: Enabling DoH experimental features in chrome://flags or edge://flags.

Even if the DoH option is activated, the protocol will not be used if the operating system specifies the local DNS server (e.g., at a university or research institute). However, if you configure one of the supported DNS servers in the network settings (Cloudflare in the example in Figure 7, i.e., 1.1.1.1), the browser uses DoH.

Figure 7: If a supported DNS server is enabled on the operating system side, Google Chrome uses DoH.

If a Chrome user can configure the DNS servers in the operating system, they can also enable DoH in this way. The only countermeasure is to block port 53 (DNS) for all internal machines except the local DNS server. In the policies, you will therefore want to set the value of BuiltInDnsClientEnabled to False [12], which keeps Chrome from using DoH, as my tests demonstrated.

Mozilla Firefox

Mozilla Firefox allows you to signal to a network that DoH is not desired. To do this, the web browser queries the use-application-dns.net domain with the operating system's DNS mechanism. If the server replies with NXDOMAIN or SERVFAIL , Firefox disables DoH.

The browser also looks for mechanisms such as Google or YouTube Safe Search and parental control filters that evaluate DNS traffic and disables DoH if it finds such software. This undocumented feature is probably based primarily on the child protection systems commonly used in the US. Additionally, deactivation only occurs if DoH is enabled by default – currently only the case in the US. However, if a user enables DoH explicitly, the user setting always takes precedence [13].

Even if Firefox uses TLS 1.3 for the DoH connection, you will see the name of the DNS server in the Server Name Indication (SNI) header when opening the HTTPS connection (the default is mozilla.cloudflare-dns.com ; Figure 8). The SNI is used to tell the server with which of the hosted servers you want to communicate and is the only way in which the web server can select the certificate that matches the website.

Figure 8: The DNS server name remains visible, even if the traffic is encrypted.

The standard for encrypting the SNI header (encrypted SNI, ESNI) [14] is currently not used for DoH requests, because the key for ESNI has to be exchanged by DoH – a chicken and egg problem. Therefore, the default DoH provider can be blocked in Mozilla Firefox by filtering for DNS requests to mozilla.cloudflare-dns.com on the DNS server.

Potential Solutions

If a company wants to prevent the use of the alternative DNS variants, it can simply block DoT on the firewall by blocking port 853 for outgoing traffic. DNSCrypt and DoH can only be blocked on the firewall by content analysis, because they use port 443 (HTTPS).

The Internet has lists of domain names belonging to service providers that have enabled DNSCrypt, DoT, or DoH [15]. However, the number of servers is constantly increasing. Blocking access to the currently listed resources is not a permanent fix. If a server offers both DoH and one or more websites on the same IP address, blocking the IP address on the firewall is not a good solution either.

A better solution is to use the distribution/policies.json file to block the DNS settings in Firefox and Chrome. On Windows, this can be done with a group policy that also takes the portable version of Firefox into account.

With more programs or operating systems supporting encrypted DNS in the future, however, a basic solution is needed. The European Telecommunications Standards Institute (ETSI) Enterprise Transport Security (ETS) standard [16] is not suitable (CVE-2019-9191), because it seeks to read the entire traffic. Group policies cannot be used for BYOD or in education roaming, because you have no access to the settings of the computers and smart devices.

In the long run, there must be a uniform way of routing encrypted DNS queries over the corresponding corporate infrastructure in enterprise environments. Blocking the external DoH and DNSCrypt providers (both using port 443) on the firewall will forever be a hare and tortoise race and therefore does not truly offer a solution. Modern firewalls with deep packet inspection could certainly detect and block the protocols and force the use of classic DNS.

The ideal solution would be something that uses DoH in open networks but prefers the DNS infrastructure of the respective institution in controlled environments. An encrypted DNS protocol could be used for communication between the clients and the DNS server.