Palo Alto Networks security experts provide an in-depth look into the risks, visibility and control of DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) traffic. Get answers on LIVEcommunity.
Organizations invest a lot of time, money and effort into securing their networks. One area that often fails to receive its due attention is DNS. According to Palo Alto Networks Unit 42 Threat Research, approximately 85% of malware uses DNS to establish a command-and-control channel, allowing adversaries an easy route to insert malware into a network as well as exfiltrate data. Since its inception, DNS has largely been unencrypted.
New encrypted DNS protocols that aim to improve the privacy of DNS are beginning to gain support amongst leading browser vendors and other software vendors. With this increase in support, enterprise networks will begin to see an increase in encrypted DNS traffic on the network. Encrypted DNS traffic that is not properly inspected or prohibited poses a security risk to the enterprise.
With proper configuration, Palo Alto Networks firewalls are equipped to prohibit or secure usage of DNS-over-TLS (DoT) and can be used to prohibit the use of DNS-over-HTTPS (DoH), allowing you to retain visibility and security over all DNS traffic on your network.
The Domain Name System (DNS) converts human readable domain names (like: www.paloaltonetworks.com) into Internet Protocol (IP) addresses (like: 34.107.151.202). When a user types a domain name into a web browser, the browser sends a DNS request to a DNS server, asking for the IP address associated with that domain name. The DNS server then responds with the IP address for that browser to use.
DNS traffic is sent over the network in plain text, unencrypted, which leaves it vulnerable to spying or being intercepted and redirected to undesired destinations. Encryption of DNS makes it harder for anyone to snoop into DNS queries or to corrupt them while they are in transit. Specifically, encrypted DNS protocols add a layer of client privacy and protection from Man-in-the-Middle tampering, while performing the same function as the traditional plaintext DNS (Domain Name System) protocol.
Two methods for encrypting DNS have been introduced over the past few years:
These encrypted DNS protocols share some common traits that purposefully lower the visibility of DNS requests from a given client and the organization as a whole. The protocols foundationally utilize the TLS (Transport Layer Security) protocol to establish an encrypted connection, between the client making requests and the server resolving DNS queries, over a port not traditionally used for DNS traffic.
While privacy from 3rd party visibility may be desirable, the methods used by these protocols also create additional security challenges for an organization wanting to maintain its own visibility into and control over its outbound network traffic. As the protocols differ in their implementations, the methods of maintaining organizational visibility and controls will differ by protocol.
Unless HTTPS traffic is being identified as DoH queries, ideally using decryption, applications already in use within your organization can bypass the local DNS settings, routing queries out to 3rd party DoH resolvers, around all existing DNS logging, monitoring, inspection, and controls.
Both Google and Mozilla have implemented DoH capabilities in the latest version of their browsers, with both companies working toward deployment of DoH as the enabled default for all DNS queries. Microsoft is also developing plans to integrate DoH into its operating systems. In addition to legitimate software companies, in the last few months, malicious parties have adapted to begin using DoH as a means of bypassing traditional enterprise controls. (As reference, please review the following articles: PsiXBot Now Using Google DoH, PsiXBot Continues to Evolve with Updated DNS Infrastructure, and An Analysis of Godlua Backdoor.) In either case, both benign and malicious DoH traffic will go unnoticed, leaving the organization blind to malicious usage of DoH as a channel for malware command-and-control (C2) and exfiltration of sensitive data.
As a best practice for DoH, we recommend configuring the NGFW to decrypt HTTPS traffic and block DoH traffic with the App-ID ‘dns-over-https’. First, ensure the NGFW is configured to decrypt HTTPS by consulting our guide on Decryption Best Practices.
Next, create a policy to apply the action to traffic identified with the App-ID ‘dns-over-https' as pictured below:
As an intermediate alternative if your organization has not fully implemented HTTPS decryption, the NGFW can still be configured to apply the ‘deny’ action to App-ID ‘dns-over-https’, but the effect will be limited to blocking certain well-known DoH resolvers by their domain name, as without HTTPS decryption DoH traffic can not be fully inspected (reference Applipedia by Palo Alto Networks and search "dns-over-http").
The DoT protocol simply utilizes the TLS protocol to provide a layer of encryption encapsulating standard DNS protocol queries, with traffic using the well-known port 853 (Hu, et al., RFC 7858, Section 6). By establishing this dedicated well-known port, the DoT protocol was designed to make it easy for organizations to either simply block the port traffic or opt-in to its usage and decryption by controlling access to the port.
Google has implemented DoT in its Android 9 Pie and later client, with the setting enabled by default to automatically use DoT if it is available. However, at the organization level, DoT’s adoption is opt-in by nature due to its requirement that network administrators explicitly allow traffic on port 853 through their firewall for this new protocol.
As a best practice for DoT, we recommend either of the following based on organizational considerations:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 8 Likes | |
| 3 Likes | |
| 2 Likes | |
| 2 Likes | |
| 2 Likes |
