Securing DNS over HTTPS (DoH)

DNS is often the first step in the cyber kill chain. Snooping on DNS queries yields a treasure trove of information and manipulating DNS resolution is one of the key methods of compromise. While innovations like encrypted DNS over HTTPS (DoH) help conceal queries, they can introduce new challenges for network security admins trying to implement PDNS mandates and inspect DNS traffic for signs of compromise. Fortunately, Zscaler’s DNS security capabilities built into the Zero Trust Exchange can help.

DNS is a key vector in the cyber kill chain

One of the first steps in any network communication is a DNS query. Given the plaintext nature of these queries, bad actors often conduct reconnaissance on the target infrastructure by snooping on DNS queries. Manipulating DNS can give attackers the ability to conduct man-in-the-middle attacks, compromise endpoints, and steal data. DNS queries are typically connectionless and easier to subvert by modifying or bypassing resolver settings on network devices or endpoints. 

At the same time, DNS queries can also serve as early warning for threats and one of the best opportunities to neutralize them before any communication is established between the target and the malware site or C2 server. Attackers know this and often take great pains to conceal their DNS activity using obfuscation techniques such as cycling through many domains and subdomains.

DNS is also often abused as the protocol for malware command and control, with TXT records being used to send commands and A records used to exfiltrate data.

One of the earliest and best opportunities to identify and neutralize threats, while identifying infected hosts and bad actors, is in the initial DNS requests and within the ongoing DNS communications. DNS is used by most legitimate web and non-web applications in at least one stage of any given session. This is often at the very beginning of any session like with normal web requests or SSH sessions but sometimes repeatedly throughout sessions.  

Bad actors recognize the need for DNS communications and the opportunity to leverage DNS in several stages of any given attack. From simply getting targets to malicious locations, post-infection mid-stage for C2 instruction, to the exfiltration of data at the end stages, DNS is often integral in an attack chain. Attackers take great pains to conceal their attacks’ DNS activity by using a variety of common means to conceal or obfuscate request and response communication, by cycling through many domains or subdomains, by abusing the protocol or using it for malicious purposes, or by poisoning entries and pointing resolutions to attacker-controlled resolvers.

Figure 1: DNS Control Breaks the Kill Chain
 

New emphasis on DNS security in an encrypted world

One of the biggest changes underway is the push to encrypted DNS. DNS over HTTPS (DoH) started out purely as a privacy tool but is now increasingly recommended by national governments worldwide as a way for industries to maintain security and integrity, in addition to privacy, in what has been up until now one of the last major services to remain widely unencrypted. Many of these same national governments led by the Five Eyes intelligence alliance and their close allies often require their national agencies to use DoH as a key ingredient in their Protective DNS (PDNS) mandates. 

Figure 2: National governments increasingly recommend–and in some cases, require–a PDNS solution

Unfortunately, attackers are also aware of both the trend toward encrypted DNS and the opportunity it presents them – particularly when DoH is often not able to be inspected or only partially inspected. Attackers are also aware that DoH is increasingly enabled by default in most browsers, configurable by users and processes. And since DoH is increasingly recommended as a best practice in the PDNS recommendation and mandate and beyond, it is no longer unusual to have DoH traffic in a corporate network and it is no longer acceptable to be simply blocked when encrypted web (HTTPS generally) is able to be inspected. 

New challenges for legacy solutions

Bad actors understand better than most that legacy-gen firewall and proxy designs – whether now “cloudified” or still trapped in virtual or physical boxes – are inherently limited to simple block/allow policies for encrypted DNS. Crime syndicates further understand that administrators are hesitant to enable TLS decryption since this often results in a noticeable performance degradation on legacy-gen appliance-based firewalls. Inspecting SSL/TLS results in a step function of added hardware spend or complicated user and traffic segmentation or added network administration complexity – usually all three at once.

Figure 3: Using only a pure-play DNS resolver service may mean some DNS queries bypass DNS security controls

Some of the more advanced legacy vendor solutions extend their general DoH block/allow policies to known resolver services. This means they trust certain third-party DoH resolvers but continue to leave the content of the DNS over HTTPS communication uninspected and policy unenforced. Because of this inspection gap, companies often need to concurrently engage and manage unintegrated third-party DNS service providers and manage policies across multiple platforms. All the while trying to ensure that no attacker malware or insider circumvents this by reaching a new unsanctioned or malicious DoH service provider.

Figure 4: Legacy-gen firewall-only and standard proxy solutions have limitations on DNS inspection and may not have or may miss DNS inspections. They also usually require another vendor to deliver a complete DNS solution.
 

Securing DNS with Zscaler using zero trust controls in the cloud

Zscaler provides a proxy and security control layer in our Zero Trust Exchange for all traffic including DNS. All DNS over HTTPS and standard DNS traffic is fully inspected regardless of what DNS resolver service is used by the endpoint. Zscaler also secures recursive and iterative requests.  

Using Zscaler for DNS brings the zero trust approach to all DNS for complete security. This means that all DNS transactions are inspected and secured according to security policy for all users, workloads, and servers, all the time. This not only fulfills the security demands of Protective DNS and other DNS security best practices but extends corporate security to all DNS over HTTPS and to all corners of the customer estate from mobile users to cloud workloads to guest Wi-Fi access points.

Figure 5: Complete zero trust DNS security

Complete zero trust DNS security steps for every DNS transaction that ensure NIST 800-207 principles including:

1. What is the identity of the user? Endpoint, workload, server?
2. Which DNS protocol is being used (DoH, UDP:53, TCP:53)?
3. What is being communicated, requested? Domain, metadata, tunnel, record type?
4. Where is the DNS transaction trying to go? Where should the DNS transaction go instead?
5. Is the inspected request side transaction allowed considering the above? What is the category of the inspected content? Allow/Block/Log request and action.
6. Does the request need to be translated to another DNS protocol (UDP to DoH, etc)?  
7. What is the inspected response back to the matching allowed request? Is this expected and allowed for the user? Domain, content, metadata tunnel, record type, etc.?  Allow/Block/Log response and action.
8. If the response is allowed, does it need to be translated back to the original DNS protocol (DoH to UDP, etc)?
9. Complete the allowed DNS transaction. Complete and enrich log data for the transaction.
    

Global scale of the Zscaler Trusted Resolver

Another unique capability of the Zscaler service is the optional Zscaler Trusted Resolver (ZTR).  The ZTR are clusters of DNS resolvers in almost all of our 150 global data centers that can be used by Zscaler customers for public recursive queries. DNS requests to any provider can be configured to be intercepted as they transit to the Zero Trust Exchange and instead are resolved at the data center instance of ZTR nearest to the requestor. Optionally the ZTR can be addressed explicitly and further remove any need for a public resolver or third-party service.

DNS resolution is not currently part of either the SASE or SSE definitions, so most of these vendors do not offer a DNS resolution capability. DNS resolution requires a separate vendor if Zscaler is not used.

Zero trust DNS security is provided for all DNS transactions independent of whether the Zscaler Trusted Resolver is used or not. The benefits of ZTR are centered on having a fast, highly available DNS service that is globally distributed and returns geographically localized resolutions. Since ZTR supports DNSSEC, there is the added advantage of high-integrity resolutions in addition to Zero Trust DNS security.

 

Complete DNS Control — better security and performance

The Zscaler Zero Trust Exchange is the only cloud-native solution that offers complete DNS security along with better DNS performance through our Trusted Resolver. DNS Control is a single, consolidated function embedded within the wider Zscaler service that directly delivers the highest DNS security efficacy with the best possible user experience all while reducing vendor sprawl, complexity, and cost.

Organizations needing to improve DNS security and privacy or facing PDNS mandates can ensure that they have protection against emerging DNS-based threats. 

All customers with ZIA and Cloud Firewall enabled can configure DNS Control rules, including full inspection of DoH traffic.