DNS over HTTPS (DoH) is a protocol for performing domain name system (DNS) transactions via an encrypted hypertext transfer protocol secure (HTTPS) channel. Regardless of the debate about DoH’s benefits for Internet users and user privacy, DoH can negatively impact enterprise network visibility and security capability by bypassing traditional DNS monitoring and protections. Adversaries have already taken advantage of DoH to evade DNS-based visibility and filtering; as a backup, staging, or primary command-and-control channel; and for data exfiltration. Though DoH is still relatively nascent, enterprises should be preparing to incorporate DoH into their DNS services. Until that happens, enterprises must act to maintain existing network visibility and security capability by disabling, preventing, or detecting DoH-based communications on their networks. In this post, I’ll discuss DNS over HTTPS and provide enterprise defenders with three strategies for security monitoring.

By incorporating the DoH protocol into their software, major browsers, such as Mozilla Firefox and Google Chrome, introduced DoH to the user population between 2018 and 2020. Now there are numerous public DoH providers and open source DoH client and server options, and DoH has made its way onto the development roadmaps of major operating systems (OSs). Incorporating DoH into applications is as easy as forming a valid DNS request and sending it in an HTTPS connection using the many existing, widely used, and often standard libraries available in a number of programming languages.

DoH is usually implemented in two ways. While both options may be available in the same software, the software will generally attempt one of the following:

1. Resolve DNS requests via default, albeit configurable, application-specific DoH settings independent of system DNS settings (Firefox takes this approach).
2. Auto-upgrade or promote a DNS request to use DoH based on the configured DNS settings of the system (Chrome takes this approach). The software checks a predefined list to see if the configured DNS resolver (e.g., 8.8.8.8) has a corresponding DoH service. This approach also seems consistent with Microsoft’s initial DoH implementation in Windows 10.

Either way, if configuration management—or even the mere presence of enterprise policies—does not explicitly disable DoH, the software generally assumes preference for encrypted DNS and will attempt to use DoH. It will first look for a corresponding DoH service or check for successful resolution via DoH, only falling back to regular, unencrypted DNS using the system settings if the DoH service lookup or DoH resolution fails. With some software, admins may need to explicitly configure the system to allow fallback to unencrypted DNS, and DoH resolution may be periodically retried.

Most enterprise application and system settings, including DoH-related settings of major browsers and OSs, are configurable and can be centrally managed, as long as

1. the software respects, more or less, enterprise policy choice and controls and
2. the enterprise develops a policy and applies and enforces the desired controls.

The onus is on the enterprise to manage its endpoints and enforce DoH policy there. This approach is a preventive and noise-reduction control and is the most straightforward option to retain the level of DNS-based visibility and capability enterprises currently enjoy: use enterprise policies to explicitly disable the use of DoH via application or system settings.

If admins control these settings, then they can largely control the use of DoH in their environments. Of course, there remain some challenges and exceptions. What about unmanaged endpoints, malware and other disrespecting software, insider threats, or a distributed workforce? Many enterprises try to implement least privilege and configuration management, yet settings get changed and software gets installed. Asset management, configuration drift, and privilege creep remain real issues for many enterprises.

Most enterprises probably have some unmanaged endpoints on their networks: BYOD, IoT, shadow IT, contractor/vendor devices, and others that they cannot access to disable DoH or directly control configuration. However, some reasonable assumptions make this challenge less of a concern, at least when it comes to DoH.

1. DoH is not currently widely implemented beyond browsers. It is in development in major OSs, but assume it is coming (it is) and that it will operate in one of the ways described above.
2. Where DoH settings are used independently of system DNS settings:
   a. DoH settings will largely remain at their defaults, which are generally set to use one or another known DoH provider.
   b. Even if DoH settings are available to change, the vast majority of users will not change these settings.
   c. Even if a user does change these settings, they will most likely be changed to use another known DoH provider. Users who know and care enough about DNS and DoH to change these settings are a minority of the user population, and they probably are not spending their time and money standing up their own DoH infrastructure. They will use an existing, reliable DoH service, such as one provided by a preferred ISP, public resolver operator, or privacy-respecting Internet company, each of which is generally a known DoH provider.
3. Where an application or OS checks a predefined list to see if the configured DNS resolver has a corresponding DoH service:
   a. An endpoint’s DNS settings either map to an entry on the list or they do not. If not, the DoH service lookup will fail, and DoH will not be used.
   b. Even if an endpoint’s DNS settings do map to an entry on the list, these predefined lists generally consist of a non-exhaustive short-list of mappings for known DoH providers.
   c. These predefined lists are user-configurable, but most users who change them will change to known DoH providers (see 2c).

Essentially, most DoH communications go to known DoH providers (user-adjusted or not). Blocking connections to these known providers allows network admins to largely control DoH use within their environments, even by unmanaged endpoints. Admins can use network and assigned DNS settings to ensure that most DoH service lookups or DoH resolution attempts fail. If an enterprise must assign DNS settings that map to an entry on the predefined list of common DNS resolvers to their DoH service endpoint, it can force the use of traditional, unencrypted DNS to those particular resolvers via TCP/UDP/53 (DNS) while denying TCP/443 (HTTPS) to the corresponding DoH services using network egress policies.

See https://github.com/curl/curl/wiki/DNS-over-HTTPS for a good starting list of known DoH resolvers. Enterprises should block both IPs and domains, if feasible, or make sure their cloud-hosted secure web gateway and protective DNS service provider have this capability.

So far, the two strategies of disabling DoH in managed endpoints and blocking connections to known DoH providers cover most non-malicious or inadvertent use of DoH. In these cases, users and software are not necessarily trying to bypass enterprise policy or controls, but DoH requests may still occur because of default settings, unmanaged endpoints, unapproved software, gaps in controls, or other reasons.

Has the enterprise fully thwarted DoH? No, not really. But it has raised the cost of using DoH and exposed its successful use, if identified, as most likely intentional, evasive, and malicious.

At this point, what would need to happen for someone to use DoH successfully on an enterprise’s network? At a minimum, there would need to be some software or code, which the enterprise does not control via configuration management or DNS settings, that can execute and form a valid DoH request to a destination that is not on the enterprise blocklist. Nine times out of ten, this software or code will be malware or its less explicitly dangerous cousin, a potentially unwanted application (PUA).

Achieving those minimums is generally not terribly hard for an adversary. Since long before DoH, the security industry has been trying to manage two old, yet ever-present and non-trivial problems: unwanted code execution and unwanted connections to dynamic and increasingly obfuscated adversary infrastructure.

“It’s not if, but when,” “prevention is ideal, but detection is a must,” and “assume breach” are adages because prevention fails. While defenders should continue doing their due diligence to manage unwanted code execution, assume that it will happen.

All that the rogue code needs to connect to adversary infrastructure is an unknown or unblocked DoH service endpoint—or really any HTTPS endpoint proxy or redirector that can forward DoH requests (e.g., couldbeanydomain.com/could/be/any/path). These days, procuring infrastructure is easy, cheap, and often automated. Readily available tools and libraries make standing up a DoH infrastructure low cost. Likewise, spinning up HTTPS proxies or redirectors is nothing new for threat actors, who often do so in ways that are unlikely to get blocked, such as using content delivery networks (CDNs), buying seasoned infrastructure, seasoning newly purchased infrastructure, using keyed requests, using custom paths, hiding within a seemingly legitimate website or even other-owned but compromised infrastructure, and using valid certificates. How do we identify such infrastructure? How can we get ahead of it?

To defend against malicious use of DoH, enterprises face two non-trivial tasks:

1. Identify adversarial infrastructure.
2. Identify DoH transactions, whether to adversarial infrastructure or not, among all the other HTTPS transactions.

As with many things in cybersecurity, defending against malicious use of DoH requires a layered strategy incorporating multiple approaches. Generally, defenders attempt to prevent or detect connections to adversarial infrastructure utilizing one or more of the following approaches.

Block outbound connections based on information about their destination (e.g., known bad IP/domain, category, reputation, etc.). Blocklisting typically relies on one or more threat intelligence ecosystems and is applied at the DNS level, web proxy, firewall, or IDPS.

Application to DoH: Blocklisting is not necessarily specific to DoH. Any HTTPS endpoint/URL could ultimately be made to field DoH requests, among other things. If an adversary can resolve and connect to their DoH service domain, DNS-level blocking is ineffective for subsequent DoH requests to that domain.

Potential issues: Blocklisting is fundamentally reactive. It often has issues with timeliness and context and is ineffective against net new or OPSEC-savvy adversary operations.

Impact to adversary: Low. Procuring new infrastructure is relatively low cost. Techniques and processes such as exploiting adversaries’ infrastructure tactics and analyzing network infrastructure as composite objects can help raise the cost for the adversary.

Break established chains of trust to decrypt and inspect network traffic.

Application to DoH: Content inspection is likely to catch unmodified DoH requests via DoH-specific content types or common URL paths and parameters: application/dns-message, application/dns-json, and /dns-query.

Potential issues: Inspection must be able to understand and decode DoH. Some security and privacy concerns require consideration.

Impact to adversary: Potentially high. It may force adversaries to employ a custom command-and-control and do more work to hide their activity.

Network traffic analysis can be applied to raw traffic to model normal network behavior and perform non-signature-based techniques to detect suspicious and/or anomalous network activity.

Application to DoH: Viable options for detection include

• analytics for newly observed domains, via traditional DNS logs, TLS server name indication (SNI), or web proxy logs
• beacon detection
• presence/absence of DNS requests corresponding to HTTP(S) transactions
• other forms of anomaly detection in general

Encrypted traffic analysis, such as inferring HTTPS semantics or other techniques, could be used if content inspection is not feasible.

Potential issues: The enterprise needs to operate and maintain infrastructure for collection, processing, and analysis; analytic development and testing is often time- and expertise-intensive. This approach requires further research for DoH-specific use cases.

Impact to adversary: Potentially high. Adversaries will try to blend in, but their behaviors are fundamentally different than users’ because the target network is essentially foreign territory to them. Investing in good NTA can be quite disruptive to an adversary.

Threat hunting has been defined as a “human-driven activity of proactively and iteratively searching through an organization’s environment (network, endpoints, and applications) for signs of compromise in order to shorten the dwell time and minimize the breach impact for the organization.”

Application to DoH: Threat hunting is not necessarily specific to DoH, unless the hunt’s hypothesis is DoH-related. It may, however, unearth suspicious activity and adversary infrastructure, which may include DoH services that other approaches or solutions missed.

Potential issues: Threat hunting requires good visibility, adequate data and infrastructure to search and answer questions, and the time and resources to do it.

Impact to adversary: High. If defenders confirm the hypothesis, then they have found a threat early and can remediate it. Disconfirmed hypotheses at least teach something about your environment or identify something to fix or adjust.

Allowlisting establishes and maintains a baseline of required or acceptable destinations and allows connections only to those while blocking everything else.

Application to DoH: Allowlisting is not necessarily specific to DoH.

Potential issues: Allowlisting often requires more effort to maintain and can degrade user experience. Different network segments or hosts require different baselines.

Impact to adversary: High. It essentially forces the adversary to compromise something on the allowlist to communicate directly with a protected asset. Allowlisting may force the adversary to make extra lateral moves through the network, which means more opportunity for detection.

The first two strategies—disabling DoH in managed endpoints and blocking known DoH providers—should mitigate the majority of DoH transactions likely to occur on an enterprise network. These include many of the real-world adversary uses of DoH to date, many of which have used known DoH providers. But fully confronting DoH in an enterprise security monitoring strategy is ultimately seated in how much DoH is considered in some broader security capabilities, such as those noted in the table above, particularly content inspection, network traffic analysis, and threat hunting efforts.

Try one of the following actions. Any of them will likely pay dividends, even beyond controlling DoH:

• discuss DoH with threat intelligence and TLS inspection vendors
• adjust existing network analytics
• develop entirely new analytics
• refine data collection requirements
• take new network measurements
• perform some exploratory data analysis
• operationalize new alerting and detection strategies
• plan to incorporate DoH into enterprise DNS services