Experience Center
Best Practices for DNS Control Rules
Zscaler recommends the following best practices for DNS Control rules. These best practices are applicable when DNS traffic is forwarded to the Zscaler service and inspected by the DNS Control module of the Zscaler Firewall.
Block Unknown DNS Traffic
Configure the default Unknown DNS Traffic rule to block traffic. This rule prevents malformed DNS queries or non-DNS traffic masquerading as DNS traffic on destination port 53. In addition, this rule also identifies and blocks certain forms of DNS abuse in real time that are consistent with certain DNS tunneling methods.
Block DNS Tunnels
Create a DNS filtering rule to block the following DNS tunnels using the DNS Tunnel & Network Apps criteria:
- Commonly Blocked DNS Tunnels: These are DNS tunnels in the denylist classification that are determined to be malicious ThreatLabZ (Zscaler's security research team).
- Unknown DNS Tunnels: These are DNS tunnels in the graylist classification that are yet to be classified and are determined to be potentially malicious by ThreatLabZ (Zscaler's security research team).
- (Optional) Commonly Allowed DNS Tunnels: These are legitimate tunnels operated by security services, but they typically have alternate, more standard modes of communication.
To learn how Zscaler detects tunneling in your network, see Detecting and Controlling DNS Tunnels.
Block Risky URL Categories
Configure the DNS filtering rule to block the following risky URL categories using the Request Categories and Response Categories criteria:
- Advanced Security: This targets both domains and IP addresses that are known to host targeted malicious content, host hijacked domains, or be used as backchannel (command and control) communication. This includes adware/spyware sites, botnets, phishing sites, Domain Generation Algorithm (DGA) Domains, and other malicious content.
- Miscellaneous: This includes sites that are not yet classified by Zscaler. There is minimal business need for allowing all unknown and unclassified applications or sites. Zscaler recommends blocking the entire Miscellaneous supercategory. Blocking the Newly Registered and Observed Domains (NRODs) category is especially recommended. NRODs are often part of attack chains, e.g., they act as termination points for DNS exfiltration using tunneling techniques or hosting drive-by and other malware before the domain is classified. There is also minimal general business need for a business-critical (or commonly-used) application to be hosted at an NROD.
- Other Risky URL Categories: Block other categories of domains and resolved IP addresses that have no business need for users, such as Gambling, Adult Content, etc. For categories that are exclusive to web browsing, you can use the URL categorization of the web secure gateway (web proxy) and display block or caution end user notifications (EUNs) to users when they browse to specific websites (beacons to the outside server in the case of HTTPS). While blocking through the secure web gateway has the advantage of displaying EUNs to users. Although the DNS Control module silently drops the packets without indicating the reason to the user, it can trigger the block action early on in the kill chain and also apply the action to all traffic, including non-web traffic (e.g., SSH).
To learn about URL categorization, see About URL Categories.
Create Block Rules for DNS Request and Response Phases
Consider adding block rules that apply to both the request and response phases of a DNS transaction. The block action on the request side is enforced immediately. The blocked request is prevented from reaching the targeted DNS resolver (Zscaler Trusted Resolver or third-party resolver), and the response phase of the transaction does not take place.
- Zscaler supports both domain-based and IP address-based categorization. However, domain-based categorization supports a wider range of categories compared to IP-based categorization. Also, domain-based categorization is more precise as they rely on the content while IP-based classification may not be accurate as multiple domains of different categories can resolve to the same IP address.
- IP-based categorization can offer an additional layer of security in cases such as DNS poisoning. For example, if a properly-categorized domain has been poisoned with a known IP address to host malicious content, the rule can still block the traffic based on the IP address. Hence, it is recommended to mirror the policy on both DNS request and response sides whenever possible.
Prevent Encrypted Client Hello (ECH)
Configure your DNS filtering rule to block a specific DNS resource record type, HTTPS, to stop ECH and prevent unmanaged encrypted traffic flows happening via the secure web gateway. To do this, you can create a rule with HTTPS selected as the DNS Request Type criteria and the action should be Block with Response Code along with "2 - Server Failure" selected as the response code, as shown in the following image. This would allow you to block the HTTPS resource records and send a Server Failure response (i.e., ServFail DNS response code according to RFC 6895) to the client.
Other response codes such as "3 - Non-Existent Domain" (i.e., NXDomain) might result in blocking the domains themselves, so exercise caution when using the Block with Response Code action, adhering to the following recommendations.
Recommendations for Using Response Codes
- NXDomain should only be used exclusively with rule criteria such as Request Categories and Response Categories. These categories can include specific URL categories (both predefined and custom) and top-level domain (TLD) categories. However, categories such as Miscellaneous that are not mapped to specific target domains should be avoided in the criteria. Alternatively, consider using less definitive and less globally cacheable response codes such as "5 - Query Refused" (i.e., Refused) and "2 - Server Failure" (i.e., ServFail).
- Defining a response code for an entire type of DNS request should be strictly avoided. For example, defining a rule to block all DNS requests of A or AAAA record types (i.e., using DNS Request Type criteria) with NXDomain would likely result in an unintended DNS outage.
To learn more, see Configuring the DNS Control Policy.