Zscaler DNS Security and Control

Reference Architecture — Zscaler for Users

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Contents
About Zscaler Reference Architectures Guides 1
Who Is This Guide For? 1
A Note for Federal Cloud Customers 1
Conventions Used in This Guide 1
Finding Out More 1
Terms and Acronyms Used in This Guide 2
Icons Used in This Guide 3
Introduction4
Key Benefits 11
New to Zscaler DNS Control?  11
Choosing a DNS Resolver Architecture  12
Resolver Option – Zscaler Trusted Resolver 12
DNS Proxy to a Remote DNS Server 15
Forwarding DNS Traffic to ZIA 15
DNS Filtering Rules and Condition-Based Actions  17
Forwarding DNS Requests to ZTR or an External DNS Server 17
Enabling Iterative DNS Lookups for Local DNS Servers 18
Blocking DNS Tunnels 19
Summary of Recommended DNS Policies 21
Deploying Zscaler DNS Control in Your Organization 22
Identifying and Bypassing External DNS Servers for Internal Name Resolution 22
Forwarding All DNS Traffic to Zscaler 22
Modifying the Firewall Policy to Allow DNS 22
Defining DNS Application Groups (optional) 22
Configuring DNS Control Policies 23
Enabling Firewall and DNS Control in a Controlled Rollout 23
Summary  24
About Zscaler 24

©2023 Zscaler, Inc. All rights reserved. ii

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

About Zscaler Reference Architectures Guides

The Zscaler™ Reference Architecture series delivers best practices based on real-world deployments. The
recommendations in this series were developed by Zscaler’s transformation experts from across the company.

Each guide steers you through the architecture process and provides technical deep dives into specific platform
functionality and integrations.

The Zscaler Reference Architecture series is designed to be modular. Each guide shows you how to configure a different
aspect of the platform. You can use only the guides that you need to meet your specific policy goals.

Who Is This Guide For?

The Overview portion of this guide is suitable for all audiences. It provides a brief refresher on the platform features and
integrations being covered. A summary of the design follows, along with a consolidated summary of recommendations.

The rest of the document is written with a technical reader in mind, covering detailed information on the
recommendations and the architecture process. For configuration steps, we provide links to the appropriate Zscaler Help
site articles or configuration steps on integration partner sites.

A Note for Federal Cloud Customers

This series assumes you are a Zscaler public cloud customer. If you are a Federal Cloud user, please check with your
Zscaler account team on feature availability and configuration requirements.

Conventions Used in This Guide

The product name ZIA Service Edge is used as a reference to the following Zscaler products: ZIA Public Service Edge,
ZIA Private Service Edge, and ZIA Virtual Service Edge. Any reference to ZIA Service Edge means that the features and
functions being discussed are applicable to all three products. Similarly, ZPA Service Edge is used to represent ZPA Public
Service Edge and ZPA Private Service Edge where the discussion applies to both products.

Clipboard-list Notes call out important information that you need to complete your design and implementation.

Warnings indicate that a configuration could be risky. Read the warnings carefully and exercise caution before
exclamation-triangle making your configuration changes.

Finding Out More

You can find our guides on the Zscaler website (https://www.zscaler.com/resources/reference-architectures).

You can join our user and partner community and get answers to your questions in the Zenith Community
(https://community.zscaler.com).

©2023 Zscaler, Inc. All rights reserved. 1

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Terms and Acronyms Used in This Guide

Acronym Definition
C2 Command & Control
DC Data Center
DNS Domain Name System
DoH DNS over HTTPS
DoT DNS over TLS
FQDN Fully Qualified Domain Name
IoT Internet of Things
IP Internet Protocol
IPSec Internet Protocol Security
GRE Generic Routed Encapsulation
NAT Network Address Translation
NRD Newly Revived Domain
NROD Newly Registered and Observed Domains
SSL Secure Socket Layer (superseded by TLS)
TCP Transport Control Protocol
TLS Transport Layer Security
TTL Time to Live
UDP User Datagram Protocol
URL Universal Resource Locator
ZDX Zscaler Digital Experience
ZIA Zscaler Internet Access
ZPA Zscaler Private Access
ZTE Zero Trust Exchange
ZTR Zscaler Trusted Resolver

©2023 Zscaler, Inc. All rights reserved. 2

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Icons Used in This Guide

The following icons are used in the diagrams contained in this guide.

Zscaler Zero ZIA or ZPA Zscaler Trusted Zscaler Dedicated Laptop with Zscaler Client
Trust Exchange Service Edge Resolver (ZTR) Load Balancer Zscaler Client Connector
Connector Installed on Phone

DNS Generic Cloud Headquarters Legacy Router Data Tunnel

Application or Location Firewall
Workload

Internet User User Laptop Hacker Laptop Infected Laptop IoT Device

©2023 Zscaler, Inc. All rights reserved. 3

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Introduction
The domain name system (DNS) is a core internet technology that works in the background of almost every request
you make. DNS works to turn names for websites and applications into internet protocol (IP) addresses. Designed in the
early years of the internet, DNS allows users to remember human-friendly names instead of a series of numbers and
delineators. DNS is an open system of hierarchical naming and resolution that relies on distributed servers around the
world.

The DNS system is used almost universally by user devices, network servers, IoT devices, cloud workloads, and SaaS
applications to request the IP address for a fully qualified domain name (FQDN). An FQDN contains the host, domain, and
top-level domain (TLD) for any internet resource. Using the website www.safemarch.com as an example:

.com The top-level domain

safemarch The domain for the organization
www The target host

A device or service makes a DNS request in an attempt to resolve a resource’s IP address, such as www.safemarch.com.
This request is made to the configured DNS server for the device or service. Through a system of requests and redirects,
that name is translated into an IP address, or the device is told the name cannot be resolved. This resolution functionality
exists across all DNS servers including the Zscaler Trusted Resolver (ZTR) service.

©2023 Zscaler, Inc. All rights reserved. 4

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

DNS Resolver and/or

User Zscaler Trusted Resolver

DNS

Recursive Search Iterative Search

1
Who is www.safemarch.com 2
Who is www.safemarch.com

3 Root DNS
Ask dns.com

4
Who is www.safemarch.com

5 .com DNS
Ask dns.safemarch.com

6
Who is www.safemarch.com

7 safemarch.com DNS
8 www.safemarch.com is a.b.c.d
www.safemarch.com is a.b.c.d

Figure 1. A user’s request for an internet resource triggers a series of name lookups by servers until the resource’s IP address is found

1. A device, workload, or application makes a request for www.safemarch.com from its configured local DNS resolver.
This happens automatically when a browser or other network application needs to connect to a remote application
or service.

2. The resolver first checks its cache to see if it has recently resolved that FQDN for another user. If the cache has a
match, the resolver returns that information, saving a full lookup. The ZTR service caches any response for the time
to live (TTL) value specified in the response. If the address is not in the DNS cache, the request is sent to the root
name server. Typically the response is to contact another server.

3. In this case, the root DNS redirects to the server responsible for the top-level domain (TLD) .com in our example.

4. The resolver sends the same request to the .com DNS server.

5. The name server for .com won’t have the address either, as that’s specific to the domain owner. However, the .com
DNS server knows who the DNS is for the domain safemarch.com and redirects the resolver to the authoritative
server.

6. The resolver sends the same request to the safemarch.com DNS server, which is the authoritative server from the
domain.

7. The authoritative server returns the IP address for www.safemarch.com to the resolver.

8. The resolver forwards the response to the user device.

©2023 Zscaler, Inc. All rights reserved. 5

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

DNS name resolution is critical to the workings of the modern internet. With remote and hybrid work, you want to ensure
your users are accessing appropriate and legitimate resources on the internet. You also want to make sure DNS is not
making your network or application look bad by slowing down access. Slow DNS resolution and application access takes
one of two forms: long resolution times by the DNS service, or using a DNS service that is too far away from the user.

User DNS Resolver Internet

DNS

1
Who is www.safemarch.com
1ms
2
www.safemarch.com is a.b.c.d
11s

3
GET www.safemarch.com
3ms
4
HTTP Success
3s

Total Time For Page Load

14.5s

Figure 2. Slow DNS response leads to a perception of slow applications and internet connections

1. The device requests resolution of a domain name.

2. The DNS server responds to the request but takes an amount of time that is noticeable to the user. This could be
due to a high volume of traffic or an issue with the server.

3. The device with its delayed response finally makes its request to the internet resource it requested.

4. The page is returned. Even though the web resource is performing well, the overall transaction was slow for the user.

Because of its role and placement in accessing resources on the internet, DNS is also a critical link in your user’s
perception of your internet and application performance. Slow DNS services make applications and website appear to
perform poorly. The page itself might load quickly, but the time it takes to locate the pages address leads to a delay in
loading time overall. Fast DNS response is critical to easing user frustration and increasing access to the internet.

The second issue involving fast resolution is ensuring that your users are connecting to a geographically local DNS service.
When you send a request to a DNS server, that server resolves the IP address based on the resources closest to the server.
If the server is on the other side of the world, it also refers you to applications that are local to the server. This can lead to
extreme application latency and application issues such as incorrect language selection.

©2023 Zscaler, Inc. All rights reserved. 6

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

For example, users in Tokyo, NYC, and Seattle all have their DNS service configured for a server in Seattle. While the
Seattle user experiences fast and appropriate resolution, the users in Tokyo and NYC don’t have the same experience.
The NYC user experiences long resolution and load times from the Seattle servers, while the user in Tokyo experiences
both of those effects and an incorrect language selection for their request. It’s critical that your users have access to fast,
consistent, and geographically close DNS services.

Zscaler solves the issue of fast, local DNS resolution through the ZTR DNS service. Zscaler has over 150 data centers
around the world that host the ZTR service for consistent, fast, and geographically local DNS resolution.

DNS Resolver and/or

User Zscaler Trusted Recolver

DNS

1
Who is onlinedating.com

2
Redirect to acceptable use
policy

Figure 3. Stopping a request at the DNS layer is the fastest way to end a transaction

In many organizations, the DNS server also acts as a first-layer content filter. This can include filtering out categories of
material to enforcing the use of safe search when searching the internet. When a user discovers that DNS is limiting their
ability to find and access content, they might try to reach a less restrictive DNS server.

DNS is more than just a way for us to have easy-to-remember names for resources. It’s also a list of websites you’ve visited
and resources you’ve accessed. What a user is asking for on the internet has also become a concern due to monitoring
and manipulation by nation states and malicious actors. In response to these threats, major browsers and public DNS
services have implemented DNS over HTTPS (DoH) to prevent tracking of user DNS requests.

©2023 Zscaler, Inc. All rights reserved. 7

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Approved DNS

Headquarters

DNS over HTTPS

Malicious DNS

Figure 4. DNS over HTTPS places DNS protocol messages inside a TLS/SSL tunnel that provides confidentiality and integrity through TLS encryption,
but also allows malicious actors to hide their activities

DoH operates by wrapping a DNS request inside of an HTTPS stream. HTTPS streams are encrypted with transport layer
security (TLS). By securely encrypting the DNS request, inspection and interference are reduced or eliminated. Direct DoH
requests can also be made by browsers and other applications, bypassing the system’s configured DNS.

While this legitimate use is a benefit to privacy advocates, it’s created a new way to bypass security controls for malicious
users or infected machines. DoH gives users the ability to resolve otherwise banned URLs, exfiltrate data from the
organization, and act as a command and control (C2) channel for botnets.

To ensure you are inspecting and applying policy to all your DNS traffic, you must enable TLS/SSL inspection. With Zscaler,
you can decrypt, inspect, and apply policy to all your traffic in nearly real time. Zscaler maintains a list of well-known
malicious DNS resolvers that can be blocked automatically. Traffic to resolvers that hasn’t been seen before is inspected,
and DNS policy is applied in the same way as traffic to known DNS resolvers. By inspecting tunneled traffic, the Zscaler
firewall can enforce your DNS policy and block malicious traffic masquerading as a DNS request.

©2023 Zscaler, Inc. All rights reserved. 8

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Headquarters

Approved DNS
DNS Port 53

DNS Port 53
Malicious DNS

DNS Port 53

Figure 5. Legacy firewalls are often configured to allow access to offsite DNS servers

As a core internet technology, DNS is often allowed through legacy firewalls if the payload conforms to what is expected
of a DNS request or response. This has led different threat actors leveraging DNS to bypass filters and leak content. Your
users might attempt to tunnel through DNS ports to avoid policy controls and inspection. DNS tunnels leverage various
forms of text attributes and record types supported by the DNS protocol to slowly leak information from the organization.
Using these same message types, DoH tunnels are leveraged by C2 servers to communicate with compromised devices
inside your organization.

Zscaler DNS Security and Control services offer mechanisms to take control of your DNS architecture and response. By
proxying the DNS request, you can enforce your organization’s DNS policies in the Zscaler Zero Trust Exchange (ZTE).
When the DNS request reaches the ZTE, the request is open and inspected. No DNS requests can bypass inspection
unless you authorize it, as you can restrict your users to only using DNS servers you specify. You can even leverage Zscaler
as your DNS resolver directly without the need to specify other infrastructure.

Headquarters

DNS Port 53

Zscaler Trusted
Resolver (ZTR)

DNS over HTTPS

Malicious DNS
DNS
Unreachable

DNS Port 53

Figure 6. Zscaler’s ZTE provides DNS resolution and the Zscaler firewall provides the ability to block DNS requests and tunnels to unapproved
sources, redirecting DNS requests to authorized resolvers when possible

©2023 Zscaler, Inc. All rights reserved. 9

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

You can choose how you respond to requests as well, either by allowing, denying, or modifying a request. You can simply
drop any requests for content or resources you don’t believe are appropriate for your users and allow the rest to pass
through. You also have the option to modify DNS responses to point at the resource of your choosing, such as a page
explaining your content policy. Many organizations reroute users’ search requests to the “safe search” version of a search
engine, such as requests for www.bing.com being redirected to strict.bing.com.

Zscaler provides the capability to examine and modify DNS requests sent using multiple protocols, including transport
control protocol (TCP), user datagram protocol (UDP) streams, and DNS over HTTPS (DoH). Zscaler’s proxy architecture
and full TLS/SSL inspection allows for the inspection and modification of DoH streams as well. This allows you to enforce
policies no matter the protocol in use by an application.

Clipboard-list ZTR does not support DOH tunnel termination.

Who is www.bing.com?

Redirect to strict.bing.com
at address a.b.c.d
Figure 7. You can modify DNS responses to point to alternative resources

DNS modification can be used to enforce search policy, such as redirecting requests for a search engine to the more
restrictive versions. In the previous example, a user tries to access the Bing search engine. The organization’s policy is to
use the strict search version of Bing, and the response is modified to redirect the user to strict.bing.com.

In some instances, you might want to reroute traffic for a traveling user to a specific resource or deny access all together.
This might be due to geopolitical concerns or increased local network security threats. By modifying the request for
resources, you can direct users to a known good instance. You can also redirect them to a page explaining why the
resource is currently unavailable to them.

With Zscaler, DNS policy is applied both to the outbound request and inbound response. The request and response are
both examined against all your policy rules. Unlike other firewall requests, if a match is made, processing of additional
rules stops and the appropriate action is taken for the request. This could be to allow, modify, or block the request or
response.

Finally, you can inspect and act on DNS tunneling by your users or devices. You might want to prevent data exfiltration
or ensure that content inspection bypass attempts fail. This coupled with reporting is another way to look for malicious
actors leveraging internet of things (IoT) devices for nefarious purposes.

Zscaler DNS Control allows you to define a granular mix of conditions that must match before action is taken. By matching
specific conditions, your policy can be tailored to your specific use cases.

©2023 Zscaler, Inc. All rights reserved. 10

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Key Benefits
● Monitor and apply policies to all DNS requests and responses, irrespective of the protocol and the encryption used.
This includes UDP, TCP, and DNS over HTTPS (DoH).

● Define granular DNS filtering rules using several DNS conditions, such as users, groups, departments, client locations,
categorization of domains and IP addresses, DNS record types, the location of countries for resolved IPs, etc.

● Enforce condition-based actions on DNS traffic, such as allowing or blocking traffic, redirecting requests to specific
DNS servers, redirecting users by overwriting DNS responses, etc.

● Detect and prevent DNS-based attacks and data exfiltration through DoH tunnels.

● Enhance your security posture by using Zscaler Trusted DNS Resolver for domain resolution.

New to Zscaler DNS Control?

If this is your first time reading about the Zscaler DNS control functionality, the following resources can help get you up to
speed quickly on the features and capabilities of the Zscaler platform.

● View a video introduction to the Zscaler DNS Control and learn more at About DNS Control (https://help.zscaler.
com/zia/about-dns-control).

● Read the Zscaler Firewall data sheet (https://www.zscaler.jp/sites/default/files/resources/en/data-sheets/zscaler-

firewall.pdf).

● Learn more about Zscaler’s Zscaler Firewall technical features at Understanding Firewall Capabilities (https://help.
zscaler.com/zia/understanding-firewall-capabilities).

©2023 Zscaler, Inc. All rights reserved. 11

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Choosing a DNS Resolver Architecture

For most organizations, running a local DNS resolver on site was normal when traffic was mostly heading to the data
center. Today we have users who are no longer on the organization’s network. VPN connections lead to slow load times
and incorrect resolutions for remote workers. Applications have also left the organization for SaaS and public cloud
alternatives. Your DNS resolver faces the same pressure to be accessible and responsive to users, SaaS applications, and
cloud workloads. Your DNS resolver also needs to be highly responsive to requests. Slow DNS requests that must travel
halfway around the globe can lead to user frustration and complaints.

Headquarters

DNS Port 53 Zscaler Trusted

Resolver (ZTR)

Approved DNS

Figure 8. Zscaler Trusted Resolver provides a consistent and scalable DNS solution, or you can select to use your own external DNS resolver

Zscaler’s DNS proxy architecture means that no matter where a DNS request is going or over what protocol, inspection
and control are still available to you. Users cannot avoid inspection by simply hiding in another protocol, choosing a
different server, or being outside the office with a disabled VPN. You have two options when leveraging the DNS proxy:

1. Resolver Option – Zscaler recommends leveraging the Zscaler Trusted Resolver (ZTR) service as your DNS resolver.
ZTR instances exist in each of Zscaler’s 150+ data centers around the world. The ZTR service is included as part of
your subscription to Zscaler.

2. Transit Option – In this model, you rely on a cloud-based DNS service. All requests are still proxied by a ZIA Service
Edge for policy enforcement.

You can choose to have Zscaler be the primary DNS resolver via the ZTR service, or continue to leverage an external
resolver. The ZIA service directs your requests to the DNS resolver service of your choice. The ZTR exists with all Zscaler
data centers and can quickly respond to your users with consistent responses. You can also forward specific domains to
the resolver of your choice, such as for local DNS servers referencing local resources.

Resolver Option – Zscaler Trusted Resolver

The ZIA service includes the ability to identify recursive queries and direct them to the Zscaler Trusted Resolver (ZTR)
service. This service is co-located in Zscaler data centers with the ZIA Public Service Edges and ZPA Public Service Edges.
This results in both faster DNS response and results appropriate to the geographic region the user is connecting from.
Together these translate into a better experience, as the user gets to the domain resolution faster by 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.

Clipboard-list If you plan to send iterative DNS queries, you need to configure a bypass option in the firewall rules.
See Enabling Iterative DNS Lookups for Local DNS Servers in this guide.

©2023 Zscaler, Inc. All rights reserved. 12

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Zero Trust Exchange

ZIA Public Zscaler Trusted

Service Edge Resolver (ZTR)

Figure 9. When a DNS request is received at a Zscaler Service Edge, it is inspected and redirected to the ZTR

When you leverage ZTR, your device DNS queries are intercepted when they reach the ZIA Public Service Edge and are
resolved by the ZTR service. The traffic is routed to ZTR by leveraging a destination NAT rule in the firewall policy that
captures and redirects all DNS requests to the ZTR service. Because the ZTR service exists at every Zscaler data center,
your DNS requests are handled locally to the user with consistent policy.

The destination NAT policy rule for ZTR is preconfigured for you and enabled by default. If you are not planning
Clipboard-list to use ZTR, you need to disable this rule for any users and devices. To learn more about configuring the DNS NAT
rule, see About NAT Control (https://help.zscaler.com/zia/about-nat-control).

©2023 Zscaler, Inc. All rights reserved. 13

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Defining ZTR as an Explicit DNS Resolver

Zero Trust Exchange

Headquarters

GRE
Tunnel

Zscaler Load Zscaler Trusted

Balancer VIP Resolver (ZTR)
or Ghost IP

Figure 10. Using a virtual or ghost IP address lets you specify an explicit DNS request for your devices, with an IP address that is shared across multiple
devices for high availability

If your organization has a policy requiring that an explicit DNS resolver be configured that matches the one used, Zscaler
provides a scalable solution and a set of IP addresses for this purpose. Using one of our global or ghost IP addresses, any
request to UDP or TCP port 53 to one of these ghost addresses is resolved by the ZTR service. By using these addresses,
you ensure the fastest response without having to worry about an outage of a specific server.

In some organizations, the network architecture is such that DNS requests reach the ZTR from outside of an established
tunnel such as GRE, IPSec, or from a Zscaler Client Connector agent. In this case, you first need to configure your
organization’s location in ZIA. Any DNS request from a known location is sent to ZTR for resolution, and all other DNS
requests are dropped. You then use the ghost IP as your trusted resolver IP for the location.

The ghost IP addresses require that a request come from a known location configured in ZIA. The DNS request can be
forwarded over Z-Tunnel 2.0, GRE, IPSec, or directly from an established location to the data center’s ghost IP address.
This model is most appropriate for locations with existing infrastructure.

● To learn more about configuring locations in ZIA, see About Locations (https://help.zscaler.com/zia/about-
locations).

● You can view a list of Zscaler IP addresses for your cloud at Zscaler Config (https://config.zscaler.com/zscaler.net/
cenr).

©2023 Zscaler, Inc. All rights reserved. 14

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

DNS Proxy to a Remote DNS Server

Zscaler Client ZIA Public Approved

Connector Service Edge DNS
Figure 11. DNS is tunneled to a ZIA Public Service Edge that inspects DNS requests in both directions, including DoH streams via TLS/SSL inspection

In the transit option, Zscaler acts as a DNS proxy. The ZIA Public Service Edge opens and inspects the DNS request. If the
request meets your organization’s policy, the request is forwarded on to the public DNS resolver. The request is forwarded
with the ZIA Service Edge IP address listed as the source, shielding your organization’s IP addresses from inspection. The
return response is also open and inspected. This allows you to modify or deny the request later in the process if the
response is found to be objectionable.

Forwarding DNS Traffic to ZIA

Protecting your organization from online threats starts by forwarding all your DNS requests to Zscaler for DNS inspection
and resolution. DNS requests and responses are both inspected against your defined policy. There are primary ways that
Zscaler receives DNS requests: from Zscaler Client Connector users over Z-Tunnel 2.0, over GRE or IPSec tunnels from
fixed sites, and directly from internal DNS resolvers or forwarders.

Devices leveraging Zscaler

Client Connector Zero Trust
and Z-Tunnel 2.0 Exchange
1

Users and devices at an

organization location over
GRE or IPSec tunnels 2
Trusted DNS
Resolver

DNS resolution for workloads

and guest Wi-Fi
3
Internal DNS
Resolver or Forwarder
Figure 12. Forwarding your traffic to Zscaler ensures all DNS traffic is inspected and policy is enforced

©2023 Zscaler, Inc. All rights reserved. 15

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

1. Devices leveraging Zscaler Client Connector and Z-Tunnel 2.0 – The Zscaler Client Connector agent is included with
your Zscaler subscription. This lightweight agent connects your devices automatically to ZIA, ZPA, and ZDX services.
Zscaler Client Connector is perfect for remote and mobile users and can be used at campus locations to enable
pervasive Zero Trust access.

2. Users and devices at an organization location over GRE or IPSec – GRE and IPSec tunnels are established typically
from routers or firewalls at your organization’s location. With a tunnel established, all your internet-bound traffic can
be forwarded directly to Zscaler.

3. DNS resolution for workloads and guest Wi-Fi – In some situations, a workload or guest user needs resolution to ZTR
without the ability to authenticate. These requests can be forwarded across an existing GRE or IPSec tunnel from a
known location, or sent directly from a known location to the nearest Zscaler data center.

It is common for organizations to leverage multiple types of forwarding to ZIA. Not every device or situation allows for the
use of Zscaler Client Connector, and not every router supports GRE or IPSec. For more information on understanding your
forwarding options, see Traffic Forwarding in Zscaler Internet Access (https://www.zscaler.com/resources/reference-
architectures/traffic-forwarding-zia.pdf).

©2023 Zscaler, Inc. All rights reserved. 16

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

DNS Filtering Rules and Condition-Based Actions

Building and enforcing DNS controls are handled by the Zscaler firewall policy engine. No matter which method you use
for resolution, DNS controls can be applied to inspect and enforce policy. Depending on your needs, you can match all
DNS traffic and enforce the same policy. In other organizations, you might want to have more granular control for different
users or device types.

As an example, an organization might have their internet of things (IoT) devices configured to use an on-site DNS server.
You would then configure your policy to reject any outbound DNS requests from an IoT device and redirect them to the
local server. This prevents any attempts to leverage DNS to control a compromised IoT device while also handling device
misconfigurations gracefully. Coupled with alerting, you can rapidly remediate any infected or misconfigured devices.

Matching DNS policy requests can be done for one or more values including users, groups, departments, defined
locations, categorization of domains, destination or resolved IP addresses, DNS application types, and time intervals.
When you’ve matched a DNS request, you can then specify an action.

The firewall’s traditional allow and block actions are supported, but Zscaler also gives you the ability to modify the
stream in real time. You can take actions to redirect DNS requests to servers of your choosing instead of what the request
specified. You can also modify the response, changing the DNS response to point at a different resource for instance.

The Zscaler firewall acts on the first match and stops processing all other rules. Ensure that your rules are ordered
Clipboard-list correctly to avoid taking an incorrect action on a request.

To learn more about creating a DNS control rule, see Configuring the DNS Control Policy (https://help.zscaler.com/zia/
configuring-dns-control-policy).

Forwarding DNS Requests to ZTR or an External DNS Server

Headquarters

DNS Port 53 Zscaler Trusted

Resolver (ZTR)

Approved DNS

Figure 13. DNS requests are directed to the Zscaler ZTR service or an external DNS server of your choosing for name resolution

As mentioned previously, the default behavior of the ZIA service is to redirect DNS queries to the trusted Zscaler DNS
resolver. A rule highlighting this setting is added to the NAT Control Policy tab indicating this redirection.

Clipboard-list The ZTR rule is enabled by default.

©2023 Zscaler, Inc. All rights reserved. 17

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

If you plan to use a resolver on the internet, such as in a public cloud, you need to create a rule allowing DNS requests
to that external resource. In this case, Zscaler will NAT the DNS request sent to the external sever instead of the ZTR. You
also need to disable the rule for ZTR.

The inputs for the rule are the fully qualified domain name (FQDN) of the DNS service you are forwarding to, and the port
number. To learn more about configuring NAT rules, see About NAT Control (https://help.zscaler.com/zia/about-nat-
control).

Enabling Iterative DNS Lookups for Local DNS Servers

A recursive DNS lookup happens between an endpoint and its configured DNS server. The endpoint asks for an address,
and the DNS server provides one or a response that no address could be found. An iterative request is what a DNS server
does on the back end for any address that it doesn’t know about.

When a request is received from a client, the DNS server begins making a series of requests. Iterative DNS requests start
at the root server’s DNS server, and through a series of referrals the server works its way to the authoritative DNS server
for that domain. The DNS server returns the result to the requester.

User ZIA Service Edge

Who is www.safemarch.com
Who is www.safemarch.com
Root DNS
Ask dns.com

Ask dns.com

Who is www.safemarch.com
Who is www.safemarch.com
.com DNS
Ask dns.safemarch.com

Ask dns.safemarch.com

Who is www.safemarch.com
Who is www.safemarch.com
safemarch.com DNS
www.safemarch.com is a.b.c.d

www.safemarch.com is a.b.c.d

Figure 14. A recursive DNS request and an iterative DNS request

©2023 Zscaler, Inc. All rights reserved. 18

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

ZIA supports customers using both iterative and recursive DNS query types, though each is quite different. Iterative
queries require specific additional configuration to transit the ZIA service, or the request will fail. By default, iterative
queries are not supported by the Zscaler DNS service as it expects to receive requests from end-user devices.

When an iterative query arrives, the service assumes it is a misconfiguration and the request is simply dropped. A policy is
therefore needed to transit DNS queries through the Zscaler service to an external DNS provider that supports responses
to iterative DNS queries.

In the iterative scenario, the client device sends the DNS query to the intended recipient. A destination NAT rule is
needed to identify the matching conditions (source IP address of the DNS server making the iterative query, for example)
and direct this traffic to transit the ZIA service. If this is not done, then the query is directed to the Zscaler DNS resolver
and ultimately dropped.

The destination NAT needs at least one of either a destination IP or destination port to complete the transit. If the original
source can be trusted to use the sanctioned destination, then simply specify the destination port again (port 53). If you
want to force DNS requests to a specific service, you would also specify its IP address or FQDN.

Rule Order Rule Name Criteria Action

1 DNS_DNAT NETWORK SERVICES – DNS NAT Port 53
Table 1. DNS destination NAT policy to forward all DNS requests

The previous example is of a 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 criterion in the rule if the goal is to transit only the
iterative requests while allowing the recursive requests to be directed to Zscaler’s trusted DNS resolver.

It’s important to note that the rule does not need to specify an IP address or FQDN of the DNS service. The only thing
required is that the destination NAT policy be set to port 53. The request is then forwarded normally by the Zscaler
service to the DNS service in the request.

● To learn more about recursive and iterative DNS control, see About DNS Control – DNS Server Traffic (https://help.
zscaler.com/zia/about-dns-control#dns_server_traffic).

● To learn more about configuring NAT rules for iterative and recursive requests, see About NAT Control (https://help.
zscaler.com/zia/about-nat-control).

Blocking DNS Tunnels

The concept of DNS tunneling leveraging DNS over HTTPS (DoH) was developed as a method to prevent interception,
modification, and recording of DNS requests. In the wake of actions by criminal threat actors and nation states, DNS-
encoded channels can pass through many organizations’ firewalls. Additionally, these tunnels don’t carry arbitrary data,
but instead leverage legitimate DNS record formats such as TXT, AAAA (IPv6 address record), and MX (mail exchange)
records to pass information in small chunks. DNS tunneling can be leveraged by malicious actors both inside and outside
of the organization.

Zscaler does not support DNS over TLS (DoT) tunnels. Zscaler recommends explicitly blocking destination port 853
Clipboard-list to prevent the operation of DoT tunnels. By blocking these tunnels, the device or application is forced to fall back
to DoH, TCP, or UDP connections which Zscaler can inspect and enforce policy on.

©2023 Zscaler, Inc. All rights reserved. 19

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Headquarters

DNS Port 53
Zscaler Trusted
Resolver (ZTR)

DNS over HTTPS

Figure 15. DNS tunnels are used as vectors for malicious actors

DNS tunnels open the organization to risk in the following ways:

1. Bypass the organization’s defined DNS protections – For technically sophisticated users, they might realize that the
organization’s DNS is not only logged but might not return the results they want due to policy. Using DoH, the user
can attempt to tunnel to an outside DNS server, such as one run by a browser developer.

2. Pass Command and Control messages to compromised systems – Command and Control (C2) messages are used to
communicate with compromised systems. Devices participating in a botnet for instance receive C2 messages telling
them the information about their next target for attack.

3. Exfiltrate data from the organization – Data can also be sent back to remote servers from clients, allowing a
compromised device to send out data from the organization. This is done using small text-based messages hidden in
what look like legitimate DNS responses.

Zscaler mitigates these risks by allowing you to inspect and block DoH tunnels. Zscaler can detect both well-known and
previously unseen application tunnels. New tunnels are identified via machine learning comparison with other well-
known tunnels, leveraging what Zscaler sees across the Zscaler cloud.

Zscaler recommends blocking all DNS tunnels if possible. Zscaler provides a default DoH tunnel policy that blocks all
tunnels, but you must enable that control for your organization. If you plan to leverage a third-party DNS server and
DoH, you can allow that tunnel specifically. If you cannot block all tunnels, consider blocking the categories Blocked DNS
Tunnels and Unknown DNS Tunnels. Blocked tunnels are services known or suspected to be malicious tunnel services.

©2023 Zscaler, Inc. All rights reserved. 20

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Summary of Recommended DNS Policies

After blocking DNS tunneling, there are other recommended policies that you might consider when deploying DNS
control. Zscaler considers these recommendations best practice, but they should be compared with your policy and
operating requirements.

1. Block all Commonly Blocked DNS Tunnels and Unknown DNS Tunnels – These entries should be blocked, as the
Zscaler ThreatLabZ team has determined they are clearly malicious or strongly suspected of being malicious.

2. Consider blocking all Commonly Allowed DNS Tunnels – These are legitimate tunnels that are operated by DNS
service providers, however each usually has alternate and more common means of communication.

3. Set the default rule Unknown DNS Traffic to Block – This stops non-DNS posing as DNS or malformed DNS requests
from being propitiated. This also identifies some forms of abuse of DNS that are consistent with some DNS tunneling
methods in real time.

4. Block the Advanced Security category of domains and IP addresses – This targets both domains and IP addresses
that are known to host targeted malicious content or are used as backchannel C2 communication or host hijacked
domains.

5. Consider blocking categories or resolved IP addresses with no organizational relevance – This can include anything
that is typically considered personal in nature, such as adult content, gambling, and social media. By using DNS to
block categories or IP address blocks, you can prevent attempts to bypass controls for all applications needing DNS
services to operate, not just web traffic.

6. Consider blocking the entire Miscellaneous category on the outbound requests – These sites typically have no clear
focus or organizational relevance.

7. Block the newly registered and observed domains (NRODs) and newly revived domains (NRDs) category – NRODs
are often part of attack chains, acting as termination points for DNS tunnel exfiltration or hosting drive-by and other
malware before a classification can be done on these domains. This list also includes NRDs, those domains whose
registrations expired and have recently been reactivated. In the case where your organization is using a new domain
(such as for a product launch), simply add that domain to the bypass list.

©2023 Zscaler, Inc. All rights reserved. 21

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Deploying Zscaler DNS Control in Your Organization

Because DNS plays such a central role to accessing internet resources, modifying your organization’s deployment should
be done in a controlled and tested manner. Taking the time to plan and test your deployment with small groups of
technical users will give you the greatest chance of success.

For more information on deploying and operating Zscaler DNS control, including a downloadable deployment
checklist for these steps, see the DNS Control Deployment and Operations Guide (https://help.zscaler.com/zscaler-
deployments-operations/dns-control-deployment-and-operations-guide).

Identifying and Bypassing External DNS Servers for Internal Name Resolution
DNS resolution can be handled either by having clients send traffic directly to Zscaler, or to a local DNS server first, which
then forwards requests on to Zscaler for non-local name resolution. If you choose to leverage local name resolution, you
need to identify the DNS subnets and/or domains associated with your DNS services. You can also use this to configure
the Zscaler firewall to forward the server’s iterative requests to a third-party resolver.

Forwarding All DNS Traffic to Zscaler

For DNS control to be completely effective, all DNS traffic (legitimate or otherwise) must be sent to Zscaler. At locations
where GRE or IPSec are in use as tunneling mechanisms, this can be handled by simply forwarding the request to Zscaler.
For mobile clients, Zscaler recommends the use of Zscaler Client Connector and Z-Tunnel 2.0. For more information on
forwarding decisions, see Traffic Forwarding in Zscaler Internet Access (https://www.zscaler.com/resources/reference-
architectures/traffic-forwarding-zia.pdf).

Modifying the Firewall Policy to Allow DNS

The Zscaler firewall policy needs to be modified to allow DNS traffic to be allowed through the firewall. This allows the
DNS control module to act on the DNS request. Blocking DoH and DoT streams should also be configured here.

Defining DNS Application Groups (optional)

DNS application groups allow you to create groups of DNS servers that can be used as policy objects when configuring
DNS control. While this step is optional, server groups often allow for easier modification of resources without having to
modify individual policy rules. For more information on configuring DNS application groups, see About DNS Application
Groups (https://help.zscaler.com/zia/about-dns-application-groups).

©2023 Zscaler, Inc. All rights reserved. 22

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Configuring DNS Control Policies

When you begin configuring DNS control policies, you should start off by building policy to handle your majority use
cases. In most instances, this will be your user base, setting policy around DNS use. After that policy is in place, you can
identify cases that need special handling for DNS, and from there it is possible to build more granular policy for those
users or devices. See Summary of Recommended DNS Policies for a list of recommended policy configurations.

Enabling Firewall and DNS Control in a Controlled Rollout

Before rolling out a change to your DNS structure across your organization, Zscaler recommends taking a phased
approach by testing with a subset of users. Ideally this would be a subset of IT users or other technical users in your
organization. This change should be done in real time for these users with the support of the team managing the Zscaler
DNS control configuration.

When making changes to your DNS infrastructure, make sure any changes won’t affect your ability to reach
exclamation-triangle the Zscaler Admin Portal or your local dynamic host configuration protocol (DHCP) servers. Additionally, it’s
recommended to provide manual backup instructions to restore access until changes can be reverted to
restore access.

After you have successfully tested your pilot group, you can begin rolling out the DNS changes to the rest of your
organization. As you roll out your changes, you might become aware of local differences that necessitate location or
group-based policy changes. These could be a location, user population, or device category that needs differentiated
DNS controls. Using the granular policy match available in the Zscaler firewall, you can create a policy that matches your
differentiated use case.

Clipboard-list Ensure that your users in these locations are aware of the upcoming changes and how to contact support
around any slowness or resource location issues.

©2023 Zscaler, Inc. All rights reserved. 23

 REFERENCE ARCHITECTURE GUIDE FOR ZTR

Summary
Taking proactive control of users’ DNS interactions gives you the ability to enforce policy at the very beginning of a
transaction. This security is applied across any application needing to resolve a name to an IP address, not just web traffic.
Zscaler DNS Control gives you the ability to monitor and control DNS activity within your organization, enforcing policy on
which servers the user can access, controlling or modifying the response, and preventing DNS tunneling exploits. These
controls expand your defense-in-depth capabilities and help ensure secure transactions, while local resolution speeds up
applications and internet access for your users.

About Zscaler
Zscaler (NASDAQ: ZS) accelerates digital transformation so customers can be more agile, efficient, resilient, and secure.
The Zscaler Zero Trust Exchange protects thousands of customers from cyberattacks and data loss by securely connecting
users, devices, and applications in any location. Distributed across more than 150 data centers globally, the SASE-based
Zero Trust Exchange is the world’s largest inline cloud security platform.

©2023 Zscaler, Inc. All rights reserved. Zscaler, Zero Trust Exchange, Zscaler Private Access, ZPA, Zscaler Internet Access,
ZIA, Zscaler Digital Experience, and ZDX are either (i) registered trademarks or service marks or (ii) trademarks or service
marks of Zscaler, Inc. in the United States and/or other countries. Any other trademarks are the properties of their
respective owners.

v20230417 ©2023 Zscaler, Inc. All rights reserved. 24