Whilst there has been a lot of discussion about the impact and usage of DNS-over-HTTPs there is so far very little data on how widely its usage has been adopted let alone what the traffic looks like. By adopting a layered approach using response policy zones and an internal DNS-over-HTTPS infrastructure it’s possible to start to get a clearer picture of DoH usage.
Within a typical Enterprise environment, you would expect the use of external DNS servers to already be prohibited. The use of DNS-over-HTTPS is thus no different from any other tunnelling software that is used to circumvent such security controls. The simple approach to resolving this issue would be to just block DoH providers at the firewall as they were identified. However, maintaining such a list, as with any black list, will present some challenges and would be better managed by commercial providers. A more layered approach provides some insight into the extent and nature of DoH usage on the network. The availability of an internal CA further increases the richness of the data that can be gathered.
The usual configuration for DoH clients requires a normal DNS lookup of the DoH server. This initial request is subject to all normal DNS controls, and can be redirected. Most clients can be expected to fail at this stage due to SSL trust issues, which is fine as the primary goal is to prevent the use of external DNS servers. Even if the SSL handshake fails it can still be logged providing more details about usage patterns. Where the DoH client either doesn’t do SSL certificate validation or trusts the internal CA we can monitor the DNS traffic and redirect through our normal internal servers.
Assuming you already have RPZ (Response-policy-zones) enabled egress DNS servers, implementation just involves standing up a DoH server and configuring RPZ rules for the DoH servers to be monitored. Optionally a logging proxy in front of your internal DoH server provides greater data gathering ability.
The two traffic flows experienced by the clients in this configuration are then:
- Client looks up DoH provider and is redirected by RPZ response to internal DoH service, but SSL handshake fails and DoH sessions terminates. The client either then falls back to traditional DNS or has no DNS capability which are both acceptable outcomes. Client IP is logged
- Client looks up DoH provider and is redirected by RPZ response to internal DoH service, SSL handshake succeeds. Fast proxy logs client user agent, request and IP then forwards request to DoH server. DoH server forwards request to normal internal DNS service and provides answer to client via proxy server.
It is of course important to remember that RPZ rules will have no effect if the client is configured to use an IP address rather than a server name. Such configurations would need to be handled at the network or firewall level.
During initial trials of this setup, we observed usage levels were low. Logging only providing an approximate upper bound, a single client may use multiple IPs within the course of a day or multiple clients may be observed on the same IP (if the DHCP lease time is low). Detailed information on client usage and RR lookups is further restricted by the SSL-client trust issue. Despite these caveats and the limited scope of the initial deployment we were already able to gather useful information. The highlights being
- There are Android and IOS applications using DoH by default with no user configuration options
- Most of those applications are using standard HTTPS client libraries
- No malicious traffic was observed during the PoC period, the majority appearing to be end users using well known browsers.
- DoH would have been causing end user issues due to the use of DNS views
- It is possible to identify the application being used via the DoH request
That there are already non-browser applications using DoH by default is of some concern but entirely predictable, that malware will follow seems likely. Most of the traffic currently appears to be end-users with well-known clients. This may well change over time and expanding monitoring of usage volume at least seems warranted.
To prevent DoH usage via IP, well known DoH providers still need to be blocked at the firewall. At present this is still a game of whack-a-mole, adding new DoH providers to the rule set as a they are discovered. However, until firewall providers can classify and block DoH traffic options are somewhat limited.