The DNS Whisperer

1a. Open the Zscaler admin console. Use any browser on your own machine.

1b. Authenticate with the credentials from your lab details email. The password in the email is a one-time password. You'll use it for this first sign-in only; ZIdentity will then prompt you to choose a new password (Step 1c) which you'll use for the rest of the labs.

1c. Choose your password for the rest of the lab. ZIdentity prompts you to set a new password right after the first sign-in. This new password — not the one-time password from the email — is what you'll use for every Zscaler sign-in throughout the labs, including when you sign into ZCC inside the VM (Step 4). Pick something memorable.

2a. Start the Skytap pod.

• Click the Skytap Portal URL provided in your access instructions.
• Your pod contains a single VM — Corp: Client PC. Ensure its checkbox is selected.
• If the machine has not already started, click the Play button to launch it.

2b. Log into the Corp: Client PC as the local Student user.

• Launch the Corp: Client PC from the Skytap portal.
• Click the Ctrl-Alt-Del icon in the Skytap Toolbar.
• Click the Credential (keys) icon in the Skytap Toolbar.
• Click the Insert Credentials icon next to the password field for the student username, or type the password manually: Admin-123!

Throughout these labs you will frequently copy commands, URLs, and configuration values from the lab guide into the lab VMs. Skytap provides a clipboard bridge between your local machine and the VM.

3a. Copy text from your host machine to the VM clipboard.

• Click the clipboard icon in the Skytap Toolbar.
• Paste your text into the Copy/paste: field that appears.

3b. Paste the text inside the VM.

• In the VM, use Ctrl+V (or right-click → Paste) to paste the copied text.

ZCC must be signed in and tunneling before the labs work — this is what carries DNS into ZTE.

4a. Open ZCC from the system tray. Right-click the Zscaler icon in the Windows system tray and choose Open Zscaler. The ZCC sign-in window appears.

4b. Sign in with your student admin credentials. Use the same Login ID as Step 1 (student@<Student FQDN>) and the new password you set in Step 1c. Paste the username via the Skytap clipboard if it's faster.

4c. Verify Tunnel Version = v2.0. Once ZCC is signed in, the Zscaler Client Connector window shows the connectivity details. Confirm Tunnel Version = v2.0 - DTLS — that's the mode the labs depend on.

4d. Verify the App Policy is "DNS Lab". Click the More tab in the left sidebar and scroll to the About section. Confirm App Policy: DNS Lab.

4e. Verify traffic is going through Zscaler. Inside the Corp: Client PC browser, open:

If ZCC is tunneling, the page reports "You are accessing the Internet via Zscaler Cloud" along with your Zscaler proxy IP and Gateway IP. If you instead see your raw public IP and a "you are not going through Zscaler" message, ZCC isn't authenticated — revisit 4a/4b.

On the lab VM, open Command Prompt and run a baseline DNS query:

Now check whether ZIA saw the query. From the Experience Center top menu:

On the DNS Insights page, click the Logs tab. Set the timeframe to the last 5 minutes. Add a filter Requested Domain Contains chatgpt and click Run Query:

From the Experience Center top menu, navigate to:

You'll land on the Windows page showing the App Profiles list. Find the row for the DNS Lab policy and click the Edit (pencil) icon in the Actions column:

The Edit Windows Policy dialog opens to the DNS tab in the Traffic Steering section. You'll make two changes here:

1. Set Domain Inclusion to * — sends every DNS query to Zscaler.
2. Add three Domain Exclusions — keeps internal-zone queries on the corporate resolver so they never reach ZIA:
   • *.corp.local
   • *.safemarch.com
   • *.qradar.com

In the Domain Inclusion field, type *. The field offers "Create ‘*’" as a suggestion — accept it:

Now move to Domain Exclusion and add the three internal zones one at a time, pressing Enter after each. Once all three are listed, click Save at the bottom of the dialog:

On the lab VM, open the Zscaler Client Connector application (double-click the tray icon, or right-click → Open). In the left navigation, click the More tab. In the About section, click Update Policy next to the App Policy line:

Run two queries from Command Prompt on the VM — one public, one internal:

chatgpt.com resolves through ZTR. intranet.corp.local returns NXDOMAIN — expected, because the host doesn't really exist; we're using it as a test name that matches the *.corp.local exclusion. The proof of the exclusion working is on the next screen: no log entry in DNS Insights means ZCC never forwarded the query.

Open Experience Center → Logs → DNS Insights → Logs and re-run the same filter (Requested Domain Contains chatgpt). The Insights pane that was empty in Step 1 now populates with rows — one per query — attributed to your user, with Resolver Gateway = ZTR:

Now change the filter to Requested Domain Contains intranet and run the query again. The pane is empty — even though you just ran the lookup on the VM. That's the exclusion working: Zscaler never saw the query, so there's nothing to log:

From the lab VM, run a baseline query against a Gambling-category domain. With no DNS Control rule yet, the query should resolve normally:

Navigate to DNS Control:

On the DNS Control page, click + Add DNS Filtering Rule:

In the DNS Filtering Rule dialog, set the rule basics:

Switch to the DNS Application tab. Set both Request and Response Categories to Gambling:

Scroll to the bottom. Set Network Traffic action to Block and click Save:

The orange Pending Activation indicator appears in the top-right of the Experience Center. Click it, then click Activate:

Confirm normal traffic still works (sanity check that you didn't block too much):

Flush the Windows DNS cache so the previous successful Gambling response isn't served from cache:

Re-run the gambling lookup. The query should now time out — the block fires before resolution:

Filter by your Rule Name = Block Gambling and an appropriate timeframe. Click Apply Filters:

The Logs table populates with rows for each blocked query. Each shows the user, source IP, requested domain, response IP, request category, response type, and the Block action:

888.com is currently caught by the Gambling block from Step 4. To provide an exception, you'll add it to a custom URL category and reference that category in a top-order DNS Control Allow rule.

6a. Create the custom URL Category. Navigate to:

On the URL Categories page, click + Add URL Category. In the dialog, set:

6b. Build a top-order Allow rule in DNS Control. Open the quick-search (top-right magnifier in Experience Center) and search for dns con, then click DNS Control:

Click + Add DNS Filtering Rule. In the rule editor, set:

Switch to the DNS Application tab. Set both Request and Response Categories to the custom category you just built. In the Action panel, set Network Traffic to Allow:

6c. Activate. Click the orange Pending Activation indicator and confirm:

6d. Verify. From Command Prompt on the VM, test a still-blocked Gambling domain (bet365.com) and the exempted domain (888.com) back-to-back:

bet365.com still times out — it's in the Gambling category but isn't in your custom exemption list, so the Block Gambling rule still fires. 888.com resolves to public IPs because the top-order Allow rule matched first:

From the lab VM, run a baseline DNS query to confirm ZTR is currently answering:

Now check how Zscaler logged that query. Navigate to:

Filter Requested Domain Contains netflix, set the timeframe to the last few minutes, and run the query. You should see one row per nslookup attempt, with Resolver Gateway = Zscaler Trusted DNS Resolver and Server Protocol = UDP:

The DNS Gateway is the named, protocol-aware abstraction a NAT Control rule will point at. Build it first, then wire the rule to it.

Open the top-right search in Experience Center (magnifier icon) and type proxies. Click the Proxies and Gateways result:

On the Proxies & Gateways page, click the DNS Gateways tab. You'll see the predefined Zscaler Trusted DNS Resolver entry. Click + Add DNS Gateway and configure:

Click Save:

On the Firewall Filtering Policy page, switch to the NAT Control Policy tab. You'll see the predefined Zscaler Trusted DNS Resolver rule already in the list (Rule Order 1). Click + Add NAT Control Rule to layer a custom rule above it:

In the Add NAT Control Rule dialog, configure the rule basics:

Switch to the Services tab. Set Network Services = DNS. Then in the Action panel, pick Redirect Request Using DoH from the DNS Gateway or DNAT IP/FQDN & Port dropdown, and select Cloudflare from the DNS Gateway dropdown:

Click Save:

Click the orange Pending Activation badge in the top-right of the Experience Center, then click Activate:

Re-run the test query on the VM:

The query still resolves; the Server: line in nslookup doesn't change — ZIA's NAT is invisible to the client. The flip lives in DNS Insights. Re-run the netflix filter and compare against Step 1:

Surface the Server IP column to confirm the upstream — every netflix row shows a Cloudflare-owned IP (typically 1.1.1.1 or 1.0.0.1 — ZIA resolved cloudflare-dns.com to one of them):

Lab 4 and the Capstone assume DNS is going through ZTR. Remove the NAT Control rule so the predefined ZTR rule takes over again — you can leave the Cloudflare DNS Gateway in place; it does nothing on its own without a rule referencing it.

7a. Delete the NAT Control Rule. Navigate back to NAT Control Policy:

On the NAT Control Policy list, find your Cloudflare DNS rule (Rule Order 1) and click the Edit (pencil) icon in the Actions column:

Scroll to the bottom of the Edit NAT Control Rule dialog and click Delete:

7b. Activate. Click the orange Pending Activation badge in the top-right and Activate. This commits the deletion:

Re-run nslookup netflix.com from the VM to confirm resolution still works. Then in DNS Insights, the Resolver Gateway column should be back to ZTR for new queries.

Before running the baseline block test, confirm Firefox isn't already using DoH — if it were, the Lab 2 Gambling block would appear broken from the very first test, and you'd waste time chasing the wrong cause.

Open Firefox on the VM. Click the hamburger menu (top-right) and choose Settings:

In the Settings search box, type dns. Scroll to Enable DNS over HTTPS using: and confirm Off is selected (the radio with "Use your default DNS resolver"):

Without DoH configured yet, Firefox uses the Windows system resolver. ZCC tunnels system DNS to ZIA (Lab 1), and the Lab 2 Block Gambling rule fires. Browse www.gambling.com in Firefox — the page should fail to load:

Return to the Firefox Settings tab from Step 1 (or reopen it via the hamburger menu → Settings, search dns). This time, flip the radio from Off to Max Protection. Confirm the provider is Cloudflare (Default):

Reload www.gambling.com in Firefox. The page loads:

Open Chrome and try gambling.com. Chrome (on Windows by default) uses the system resolver — plaintext DNS to ZCC, then ZIA. The Lab 2 rule fires:

Navigate to SSL Inspection policy:

Click + Add SSL/TLS Inspection Rule. Configure the basics:

Scroll to the Action section. Set Action = Inspect. Leave the other fields at their defaults for the lab. Click Save:

Click the orange Pending Activation badge in the top-right of the Experience Center, then click Activate:

Before re-testing, clear out any cached state from the previous DoH-bypass run — otherwise Firefox or the OS may serve the old resolution and the test will look like SSL Inspection didn't work:

1. Quit Firefox completely (close all windows, then File → Exit — not just the tab).
2. Open Command Prompt and flush the Windows DNS cache:
   Windows Command Prompt

   ipconfig /flushdnscopy
3. Relaunch Firefox and browse to www.gambling.com.

The page now fails to load — same as the baseline at Step 2:

Filter by Requested Domain Contains gambling. With SSL Inspection on, the DoH queries are now visible to ZIA. The Insights row detail tells you exactly how each query reached the resolver: