Configuring Client Connector for DNS Control (and Cloud Firewall)

Follow these example steps to insure that DNS traffic is sent to the Zscaler Trusted Exchange (ZTE) from Client Connector users and endpoints.

The steps below are intended to be a simplistic explanation for the purposes of highlighting general guidelines for configuring Client Connector. It is important to consult the more comprehensive Helpdocs configurations in order to fully assess the impacts and decide on an approach (among other considerations) prior to making changes or enabling.

Step 1: Enable Tunnel 2

First step is to ensure that the Client Connector can send non-web traffic. To do this, ensure that Tunnel 2 is enabled.

If migrating from a Tunnel 1 deployment to a Tunnel 2 deployment, there are a series of best practice recommendations that should be examined to do this in both a comprehensive and non-disruptive manner. It is therefore important that the Helpdocs for tunnel 1 to 2 migration are consulted, understood, and part of the migration plan.

Two further considerations here:

First is that Cloud Firewall policy will apply to any non-web traffic that is sent to the Zero Trust Exchange (ZTE and specifically ZIA). Today, Cloud Firewall can apply policy to traffic forwarded via Tunnel 1 or forwarded from fixed Location deployments (GRE, IPSec, etc). Please see the Cloud Firewall Helpdocs and take note of configurations like the “Enable Firewall for Z-Tunnel 1.0 and PAC Road Warriors” in Advanced Settings and the required enablement of Cloud Firewall for each fixed Location in the Location Management of the Admin settings.

Second, enabling Tunnel 2 is also a step towards enabling Cloud Firewall for your users. This ensures that corporate security follows these users wherever they go and branches and locations are no longer constrained by the functional and operational limits physical or VM/logical legacy-generation firewalls. This means that all traffic is examined with DPI, any non-standard web is directed to the SWG, and IPS signature rules are applied to all non-web threats – all in addition to DNS Control for standard DNS and DNS over HTTPS (DoH).

A final note is that new Zscaler customers will soon have Tunnel 2 enabled by default and this will become the standard Client Connector deployment especially targeting remote users (Road Warriors). The above described first step is for existing customers who have not already enabled Tunnel 2.

Step 2: Set your Includes and Excludes

The Includes tell what IPs, ports, protocols, and domains should be sent to the ZTE for DNS Control to examine. The Excludes indicate what should not be sent. Generally, the most specific designation here wins.

To ensure that standard DNS is sent we want to add a more specific Destination Inclusion to target just the standard DNS traffic and enter “0.0.0.0/0:53”.

Domain Inclusions for DNS can start by assuming “" meaning “all domains should be included and sent to ZTE”. Consider adding any private domains that are not publicly resolvable to the Domain Exclusions list like ".INTERNAL” or “*.MYCORPDOMAIN.NET” etc.

image

Step 3: Modify Further According to Real Use Case

Any DNS over non-standard ports needs to be explicitly added to the port Includes but also the DNS network service needs to be modified to include the non-standard DNS. Also, the

DNS over HTTPS (DoH) is not considered non-standard DNS and if web traffic is already being directed to the ZIA then DNS Control policy will apply to DoH traffic as it does to

Be sure to consult the Helpdocs for Client Connector for more details: Policy & Administration Settings

Endnote: What this Client Connector Config Doesn't Cover for DNS

Well, quite a bit and hence the reason for the noted caution above. But most notably, organizations that have a DNS server cluster on premises may wish to start getting the benefits of DNS Control security and performance by simply forwarding their recursive DNS queries to the Zscaler Trusted Resolvers (ZTR) and implementing security policies for these forwarders.