Zscaler Internet Access (ZIA) supports customers using both iterative and recursive DNS query types though each quite differently. Iterative queries require specific additional configuration to transit the ZIA service or they will fail.
This document identifies the best practice for configuring iterative queries.
The same configurations supporting iterative queries can also be used to transit recursive queries if the use case arises.
Benefits of using the Zscaler Trusted DNS Resolver
The ZIA service includes the ability to identify recursive queries and direct them to Zscaler DNS servers located (often locally) in the Zscaler data center. This results in both a generally faster DNS response and a more contextually regionalized query. Together these translate into a better experience as the user gets to the domain resolution faster and pointing to an instance that is closer to where they are geographically located – all while guaranteeing the use of a trusted DNS resolver regardless of device configuration.
Why a policy is needed for iterative queries
The problem is that iterative queries are by definition not supported by the Zscaler data center DNS servers and so cannot receive the benefits described above. The purpose of iterative DNS queries is that a DNS resolution wants to walk through the steps (iterations) of resolving a DNS request. For example.com, this starts with the global root servers (root server hints or the “.” portion) to get an authoritative DNS for .com and then the authoritative DNS for example.com etc.
When an iterative query arrives by misconfiguration or otherwise to the Zscaler DNS, the request is simply dropped. A policy is therefore needed to transit DNS queries through the Zscaler service to an external DNS provider that may support responses to iterative DNS queries.
How DNS queries can be handled in ZIA
The illustration below highlights how iterative DNS queries (Host Case A) and recursive DNS queries (Host Case B) can be handled in the ZIA service.
In the iterative scenario, the client source IP:port send the DNS query to the intended recipient (8.8.8.8:53 or any service that supports responses to iterative queries). A Destination NAT rule is needed to identify the matching conditions (source host IP of the DNS server making the iterative query, for example) and direct this traffic to transit the ZIA service. If this is not done as shown in the Case A illustration above, then the query will be directed to the Zscaler DNS resolver and ultimately dropped.
The destination NAT needs at least one of either destination IP or destination port to complete the transit. If the original source can be trusted to use the sanctioned destination (8.8.8.8 in this example) then simply specify the dest port again (port 53).
The above is an example of destination NAT rule used to transit DNS traffic and is the current best practice for supporting iterative DNS queries. This rule as defined transits all DNS traffic regardless of whether it is iterative or recursive.
Add the IP address sources of the iterative DNS servers as a criteria in the rule if the goal is to transit only the iterative requests while allowing the recursive to be directed to Zscaler’s trusted DNS resolver.
Going Forward: Changes in 1H-2021 (6.1)
In order to make it clearer to the administrator that the default behavior of the ZIA service is to redirect DNS queries to the trusted Zscaler DNS resolver (Case B in illustration above), a rule highlighting this setting will be added to the NAT Control Policy tab indicating this redirection. The Zscaler Trusted DNS Resolver rule will be default enabled (see image below).
In order to support iterative queries transiting the ZIA service, the rule will need to simply be disabled. Once disabled, the DNS traffic will flow as in Host Case A and directly to the originally requested DNS service.