Disaster Recovery Deployment Guide

White Paper

Disaster Recovery

Deployment Guide

V1.3

White Paper

Contents

1 Introduction 3

1.1 About Disaster Recovery 4

2 Disaster Recovery Prerequisites and Considerations 4

2.1 Platform Prerequisites 5

2.2 Unavailable Features during Disaster Recovery 5

3 Zscaler Disaster Recovery Architecture 6

3.1 Zscaler Internet Access (ZIA) 7

3.2 Zscaler Private Access (ZPA) 7

4 Planning 8

4.1 ZPA DR Infrastructure Capacity 9

4.1.1 App Connector Capacity Planning 9

4.1.2 ZPA Private Service Edge Capacity Planning 9

5 Disaster Recovery Conguration 10

5.1 DNS Conguration 11

5.2 ZIA Conguration 12

5.3 ZPA Conguration 14

5.3.1 ZCC Portal Conguration 14

5.3.2 ZPA Portal Conguration 14

6 Testing 16

7 Deactivating Disaster Recovery 18

8 User Experience during Disaster Recovery 19

8.1.1 ZIA Users 19

8.1.2 ZPA Users 20

White Paper

Introduction

This guide provides an overview of

the Zscaler Disaster Recovery (DR)

functionality, considerations for activation,

feature constraints, and includes detailed

step-by-step conguration activities

needed to congure, activate, test, and

recover from a incident. In addition, the

document provides links to relevant help

articles, which provide additional detail

and conguration options.

White Paper 4

About Disaster Recovery

The Zscaler Cloud oers exibility, scalability, and security for users accessing applications from anywhere

through a robust cloud infrastructure with regional redundancy, core infrastructure standbys, operational

drills, and procedure planning. Zscaler has a long history of near-perfect uptime backed by best-in-class

service-level agreements. However, a resilient solution must operate under black swan events where the

cloud is not accessible due to natural disasters, technical failures, and human error.

With Zscaler DR, organizations can quickly restore access to Mission Critical Applications, even in events

when the Zscaler Cloud is not available. The customer can initiate DR mode according to its Business

Continuity plan to ensure current users continue accessing essential business applications. Once the event

is over, the customer can restore the regular operation of

the platform.

Disaster Recovery Prerequisites and Considerations

The underlying assumption during Disaster Recovery mode is that even though the Zscaler Cloud is not

available, the customer’s underlying infrastructure services remain operational. However, DR prerequisites,

congurations, and infrastructure components must be in place before a Disaster Event. In addition,

features and protections that rely on communication with the Zscaler Cloud services will be disabled

tenant-wide while DR mode remains active and selectively during DR test mode.

DR for ZPA applications is enabled at the Application Segment Level. Zscaler recommends moving non-

mission critical or risky applications under DR to new application segments.

Disaster Recovery has three operation modes:

• O: Normal operations, ZPA Private Service Edge (PSE), App Connectors, and Zscaler Client Connector

(ZCC) operate in cloud mode.

• On: DR Mode active. Only currently enrolled and authenticated users can access mission critical

applications within application segments marked for DR through App Connectors and PSEs

congured for DR.

• Test: Test Mode, used for testing DR Mode by applying DR to a group of users.

White Paper 5

Platform Prerequisites

The prerequisites listed below are known to be applicable at the time of publication. For the latest

information, review the “Understanding Disaster Recovery” article.

Platform prerequisites

Item Description

DNS Records Ability to create a separate domain, TXT, and A DNS record for disaster recovery.

ZCC Versions Windows 4.0 and above.

MacOS 3.7.1.38 and above.

ZCC prerequisites

Network Connectivity End User devices must be able to reach DNS to resolve the Disaster Recovery domain.

ZCC must be able to access the Zscaler-provider global database allow list.

ZCC must be able to reach the ZPA Private Service Edges.

ZIA prerequisites

Custom PAC File The Custom PAC le must be reachable by HTTP or HTTPS when the ZIA service is unavailable.

ZPA prerequisites

PSE and App Connector Use the latest ZPA PSE and App Connector release.

DNS Records DNS A records congured with the public IP of PSES enabled for DR.

Data Residency Data Residency requirements should be documented and considered during DR Planning

Table 1 Disaster Recovery prerequisites

Unavailable Platform Features

Feature Description

Authentication and enrollment Only devices enrolled and authenticated users will be able to use ZIA, and ZPA

Reauthentication Users who log out of ZCC will not be able to reauthenticate until DR Mode is disabled.

The Zscaler SAML assertion validity is extended by 14 days(congurable in the ZPA UI) from

the date the SAML assertion was issued when DR is activated.

Conguration Changes Conguration changes (App Proles, Policies, Zscaler hosted PAC les) will not be available.

Log Streaming Service Logging during DR is unavailable at the time; engage with Zscaler Professional Services for

additional information.

Source IP Anchoring

Applications (SIPA)

SIPA applications are not available during DR at this time **

Data Protection DLP, Filetype Control, Firewall, Sandbox, SSL Inspection, and Threat Protection are disabled

Unavailable ZIA Capabilities during DR Mode

ZIA Policies Global Trac Forwarding Action applies (Send Trac, Disable Trac, Predened-Trac)

Unavailable Features during Disaster Recovery

The following information was current at the time of publication, for the latest information, review the

article named “Understanding Disaster Recovery.”

White Paper 6

Unavailable Platform Features

Web Security Malware Protection, Advanced Threat Protection, Secure Browsing

Web Access Control URL & Cloud App Control, Bandwidth Control

Firewall Filtering DNS, FTP, IPS, and Forwarding Control

Unavailable ZPA Capabilities during DR Mode

ZPA Policies ZPA Policies are unavailable during DR Mode.

Portals and Browser Access Privileged Remote Access Portal, User Portals, Browser Access are unavailable.

Connector Management Branch and Cloud Connectors are unavailable during DR.

App Connector and PSE

Enrollments

The infrastructure necessary to support users during DR must be deployed and online before

the DR Event.

Machine Tunnels Users without authenticated cached credentials and a network path to authentication

infrastructure may be unable to login

Table 2 Unavailable Features during DR Mode

** SIPA is available under specic congurations. SIPA Applications within a DR-enabled App Segment, App Connector, and PSE may be available

during DR. The customer is encouraged to test their SIPA deployment using DR Test Mode. For additional information, please contact the

Professional Services team.

Zscaler Disaster Recovery Architecture

Zscaler DR features aim to enable existing authenticated users and network-level access to mission critical

applications identied in the customer’s Business Continuity Plan. Mission critical Applications are those

essential applications of suites of applications required by the business to operate eectively.

The underlying assumption for DR mode is that the Zscaler cloud is unavailable. Therefore, Zscaler utilizes

DNS as an external service to initiate DR Mode. As such, the customer must register a domain name for

disaster recovery and create a set of DNS A and specic TXT records. To simplify the creation of the DNS

TXT records, Zscaler provides the Zscaler Record Generation tool. Review the DNS Conguration Section

for details.

Client Connector

Business as Usual

ZPA

Hosted in Data

Center or Public Cloud

ZIA

Internet

& SaaS

Internal

Apps

Zero Trust

Exchange

Zero Trust

Exchange

DR Private

Service Edge

Client Connector

Disaster Recovery (DR) Mode

Internet

& SaaS

DR activated via

special DNS record

Internal

Apps

Internet & SaaS (ZIA)

Client Connector

allows internet access

to whitelisted

domains

for cyber or data

protection

Private App Access (ZPA)

Client Connector redirects

No new user authentication

In Oce User

White Paper 7

Zscaler Internet Access (ZIA)

ZIA utilizes ZCC to protect web users’ trac by

forwarding user trac to the Zscaler service

ensuring that access policies are enforced. In

addition to protecting users during normal

operation, ZCC downloads the Zscaler pre-

dened global allow list** every 24 hours. It also

queries the DNS service periodically to determine

if DR mode is activated. When ZCC detects

that DR is activated, it displays a “Safe Mode”

notication popup, adds “Safe Mode” to the ZCC

GUI, and creates notication log entries indicating

that Internet Security Safe Mode has started.

ZIA DR provides three dierent trac forwarding

actions congured through App Proles within

the ZCC Portal. Zscaler recommends using

the Allow Trac to pre-selected destinations

trac action to continue providing internet

access to whitelisted and known destinations.

Review the ZIA Conguration section for details.

Alternatively, customers can bypass all internet

trac through direct internet access or disable

access altogether, depending on the company’s

risk tolerance. Review the article “About Disaster

Recovery” for details on the three

forwarding actions.

NOTE: Zscaler recommends reviewing all explicit

bypass policies and mission critical destinations

against the Zscaler pre-dened allow list. Add

any missing locations to the Custom PAC le;

otherwise, users won’t get access to applications

with DR Mode activated.

Zscaler Private Access (ZPA)

ZPA DR modes leverage the existing ZPA

Infrastructure (App Connectors and ZPA Private

Service Edges) to provide network-level access

to mission critical applications and uses DNS to

activate and deactivate DR Mode.

The ZPA Private Service Edge (PSE) manages

connections between ZCC and App Connectors.

During regular operation, the PSE and App

Connectors download the relevant congurations

from the ZPA Cloud. The App Connectors, in

turn, provide the secure authenticated interface

between a customer’s servers and the ZPA cloud

and are usually co-located as close as possible

to the enterprise applications. For a detailed

description of PSEs and App Connectors, review

the “About ZPA Private Service Edges” and

“About App Connectors” help articles at https://

help.zscaler.com.

The ZPA components query DNS periodically to

determine if DR mode is active by the contents

of the TXT record. Once DR is activated, the

following actions occur:

• The Zscaler SAML assertion validity is extended

by 14 days to prevent users from losing access

to DR applications when they reach a timeout.

The value can be congured in Disaster

Recovery Settings in the ZPA Admin Portal

• App Connectors and PSEs enabled for DR will

reboot to enter DR mode.

• ZCC will resolve the disaster recovery domain

A record and connect to the PSE behind the

resolved IP.

• ZCC downloads the DR apps listed in the local

conguration le of the PSE.

• ZCC forwards the mtunnels for the DR Apps to

the PSE to provide network-level access to

the applications.

Review the ZPA Disaster Recovery Conguration

section for conguration details for the ZCC

Portal, App Connectors, and PSE.

White Paper 8

Planning

Enabling Disaster Recovery has several

implications for business operations depending on

enabled product features. Therefore, the decision

criteria for activation must be documented and

integrated into customers’ existing Business

Continuity Plan. Consider the following factors

when creating the plan.

• Application Selection. DR is enabled at

the Application Segment level. To control

mission critical applications for DR only,

Zscaler recommends creating new application

segments with only the desired applications.

Non-mission critical applications should not be

part of the group.

• Situation assessment. Ensure the situation

is classied as a disaster, based on business

impact (users/locations impacted, loss of

productivity), restoration times, and impact

of operating under reduced risk controls

(unavailable features).

Customers should utilize Zscaler’s Trust

Center as a data point to determine if a

DR event should be activated. Trust Center

provides the status of Zscaler’s Cloud Services,

including maintenance schedules, incidents,

and advisories.

• Restoration time. Consider the expected

resolution time for the outage versus the

business risk of not activating Disaster Recovery.

Disaster Recovery activation/restoration

has a dependency on DNS propagation

time. Consider the result of DR Activation /

Restoration tests in the decision process.

• Communication plan. Ensure a clear

communication plan outlines how the

information will be shared with all relevant

stakeholders, including employees, customers,

vendors, and partners. The communication plan

should dene what applications will continue to

be operational during Disaster Recovery.

• Recovery Time Objectives (RTOs) and

Recovery Point Objectives (RPOs). Validate

that the recovery time and data loss objectives

specied in the disaster recovery plan are

relevant, contain steps that include Zscaler

services, and are achievable given the specic

circumstances of the event.

• Resource availability. Ensure access to the

necessary resources such as networking

team, DNS administration, Networking, and

Applications to activate and execute the disaster

recovery plan.

• Data Residency requirements. DR-enabled

PSEs should meet data requirements during DR,

adjust the infrastructure, or document the risk

as required.

Each organization may have additional decision

criteria for activating a Disaster Recovery

Plan. Zscaler recommends engaging with the

appropriate teams to incorporate the Zscaler

infrastructure and DR activities.

During the instantiation of DR mode, the user may become briey disconnected from their applications.

When DR is fully operational, users can only use mission critical applications enabled for DR.

White Paper 9

ZPA DR Infrastructure Capacity

ZPA DR Mode relies on PSEs and App Connectors to provide network-level access to mission critical

applications during a DR event. During normal operations, PSEs and App Connectors can be added to

the ZPA Service Groups anytime. Deploy enough App Connectors and PSEs capable of handling capacity

during a DR Event before the event. Adding additional devices for scale during DR Mode is not possible.

DR devices must be online before activating DR.

App Connector Capacity Planning

App Connectors provide the secure authenticated interface between a customer’s applications and the ZPA

cloud and are usually co-located with the enterprise applications with connectivity to the PSE. Review the

document “About App Connectors.” for the latest information. The number of App Connectors required

is based on the aggregate throughput and the number of applications enabled for the Double Encryption

feature. For a detailed understanding of throughput, please review the “Understanding App Connector

Throughput” article.

At the time of publication, the following were the recommended sizing requirements for most platforms.

For the latest information, review the article “App Connector Deployment Prerequisites” and the

appropriate deployment guide for your platform located at https://help.zscaler.com/zpa/app-connector-

management/app-connector-deployment-guides-supported-platforms.

Spec Recommended Value

Memory 8 GB of RAM

CPU 2 CPU cores(Xeon E5 class) for physical machines without hyperthreading

4 CPU for virtual machines with hyperthreading

Disk Space 16 GB thin provisioned

Network Cards 2 NICs congured in a bonded pair

Max Aggregate throughput 500 Mbps per App Connector

Table 6 App Connector Recommended Specications

Zscaler recommends deploying a larger quantity of App Connectors with lower specications rather than

fewer App Connectors with higher specications to scale horizontally in an N+1 conguration where N is

the number of App Connectors required per the sizing requirements. DR mode does not require dedicated

infrastructure for operation if the infrastructure is properly sized to include both DR and DR Testing events,

refer to the DR testing section for additional details.

ZPA Private Service Edge Capacity Planning

The quantity of PSEs used in an environment is determined by throughput and number of users

connecting to ZPA. The following specications were accurate at the time of publication, please reference

the help article “ZPA Private Service Edge Deployment Prerequisites” for the latest information. Platform-

specic deployment guides can be found in the “Private Service Edge Deployment Guides for Supported

Platforms” article.

White Paper 10

For a comprehensive guide on deploying ZPA Private Service Edges review the “Private Service Edge

Management” section at https://help.zscaler.com/zpa/private-service-edge-management.

Spec Recommended Value

Memory 8 GB of RAM for up to 2,000 connected users. Add 1 GB for every additional 1,000 active

connected users

CPU 4 CPU cores(Xeon E5 class) for physical machines without hyperthreading

4 CPU for virtual machines with hyperthreading

Disk Space 16 GB thin provisioned

Network Cards 2 NICs congured in a bonded pair

Max Aggregate throughput 500 Mbps per App Connector

Table 7 PSE Recommended Specications

ZPA Private Service Edges are designed to scale elastically. To support the total throughput required for DR

Mode,add additional ZPA Private Service Edges to the appropriate ZPA Private Service Edge group using

the corresponding Provisioning Key. Zscaler recommends deploying ZPA Private Service Edges in pairs

(N+1), where N is the number of ZPA Private Service Edges as per the sizing requirements. DR mode does

not require dedicated infrastructure for operation if the infrastructure is sized properly to include additional

capacity for both DR and DR Testing events; refer to the DR Testing section for additional details.

NOTE: Plan for Scalability. App Connectors and PSEs capable of scaling to support user and application

capacity during a DR event must be completed prior to the DR event. Adding additional devices during DR

Mode is not possible. DR devices must be online before activating DR.

Disaster Recovery Conguration

Perform DR conguration after identifying mission critical applications and site destinations, assessing App

Connector and PSE Capacity, reviewing considerations with the company’s DR and Security Teams, and

deploying any required additional infrastructure.

This section covers Zscaler ‘s recommended settings and provides an overview of the conguration. For

detailed conguration, review the ZIA Disaster Recovery article at https://help.zscaler.com.

The high-level steps for DR conguration are listed below:

1. Conguration of DNS disaster recovery domain and DNS TXT records.

2. Enabling DR features for ZPA and ZIA for each App Prole in the ZCC portal.

3. Conguration Trac Forwarding Actions for ZIA.

4. Enabling DR for mission critical Application Segments, App Connectors, and PSEs.

White Paper 11

DNS Conguration

Disaster Recovery Mode is controlled by the disaster recovery domain DNS TXT record tags. DR can be

triggered upon uploading the TXT record or scheduled using the start and end time parameters.

The DNS TXT records follow a format analogous to the Domain Key Identied Mail (DKIM) format. For a

comprehensive description of the various parameters and tags available, review the article “Creating DNS

TXT Records.” Zscaler recommends using signed DNS TXT records; unsigned DNS TXT records for DR

operations due to the additional controls required. Unsigned DNS TXT records are also available.

Although the DNS TXT records can be created manually, Zscaler recommends using the Zscaler DNS

Record Generator tool to ensure proper syntax and sign the records. At the time of publication, the tool is

only supported for Windows OS Devices and must be run as an administrator. For the latest information

and installation details, review the article “About the Zscaler DNS Record Generator.”

1. Select and register a Disaster Recovery Domain. Choose or create a new domain dedicated to DR.

The same domain name can be used for ZIA and ZPA and will be entered in the ZCC and ZPA

Admin portals.

2. Download the Zscaler DNS Record Generation tool. In the ZPA Admin Portal, navigate to

Administration -> Settings -> Disaster Recovery and click the download icon

3. Install the Zscaler DNS Record Generation tool. Use this tool to create the DNS TXT records and the

signature Disaster Recovery Key Pairs.

4. Create key pairs. If keypairs have not been created, use the Zscaler Record Generator tool to create

keypairs and store them according to the company’s security policy.

5. Generate Signed DNS TXT Records. Create the signed DNS TXT Records with the following settings:

Generator Tool Prompt Value Notes

Signed DNS records? Yes Zscaler recommends only using signed records to perform

DR operations.

Create a key pair? Yes The Zscaler tool will generate a 2048-bit RSA key pair necessary

for signing operations, les are saved in the /Files folder within the

install directory named: dr_privatekey.pem and dr_publickey.pem

Care must be taken to secure the private key according to company

policy.

Disaster Recovery needs to be

congured for ZIA?

Yes If activating DR for ZIA, otherwise set No

Overwrite ZCC Portal

conguration

No Zscaler recommends using the Pre-dened Destinations option that

is only congured in ZCC Portal

White Paper 12

Generator Tool Prompt Value Notes

Disaster Recovery needs to be

congured for ZPA

Yes If activating DR for ZPA, otherwise set to No

Set the disaster recovery status

for the disaster

recovery domain;

On Enable DR Mode, other options are O to deactivate Disaster

Recovery and Test to activate DR Test Mode

Do you want to start disaster

recovery now?

Yes Setting the value to Yes will activate DR mode once the DNS TXT

record is uploaded and DNS propagates.

To schedule, DR activation set the value to No and enter the date

of the activation in yyyy-mm-dd format and time in UTC using the

hh-mm-ss format

Default disaster recovery

activation ? (runtime = 7 days)

Yes By default DR remains active for 7 days from the start time.

To schedule an end time

Default disaster recovery

activation? (custom duration)

No Enter the date for deactivation in yyyy-mm-dd format and time in

UTC using the hh-mm-ss format

Table 8 Zscaler DNS Record Generator Tool values for initial conguration

6. DNS TXT Records. The DNS TXT records will be stored in the /Files folder within the Zscaler Record

Generator Tool program folder. Uploading the DNS TXT record to DNS will perform the action

congured in the tool.

7. ZPA DNS A Records. DR-enabled PSEs must be publicly accessible and reachable by the ZCC.

Each publicly accessible DR-enabled PSEs, requires a DNS A record created within the customer

environment. During Disaster Recovery mode, ZCC relies on DNS resolution to determine which PSE it

will connect. Refer to the customer’s DNS provider to determine how to implement Global Server Load

Balancing if PSE selection by round-robin is unsuitable for deployment.

ZIA Conguration

DR mode for ZIA allows enrolled users to continue accessing internet applications when the ZIA service is

not available, based on the Trac Forwarding Action. Congure the Trac Forwarding Action in the App

Proles section within the ZCC Portal:

1. In the ZIA Admin Portal, go to Policy -> Zscaler Client Connector Portal

2. Click App Proles

3. For each supported platform (Windows and macOS), edit an existing policy or create a new

one as applicable.

White Paper 13

4. Scroll down to the ZIA Disaster Recovery Section and toggle Disaster Recovery service

5. Congure ZIA Disaster Recovery Settings

Setting Input Description

Activation Domain Name Enter the disaster recovery domain name

Domain Public Key Upload the dr_publickey.pem le created with the Zscaler Record Generator Tool. This key is

used to validate the DNS TXT records

Disaster Recovery Trac Action Zscaler Recommends using the Pre-Selected Destinations option along with Use Zscaler Pre-

Selected Destinations and Use Custom Destinations.

The Zscaler Pre-Selected Destination list contains whitelisted URLs; review the article “About

Disaster Recovery” for the current list location.

Enter the URL (including the http or https prex) for a custom PAC le not hosted in Zscaler.

The Custom PAC le should include three types of domains:

• External mission critical domains not included in the Global Allow list.

• All the bypassed domains not contained in Zscaler’s pre-selected destination list.

• Domains included in Zscaler’s Global Allow list that the customer wishes to explicitly block

For custom PAC le examples, review the Trac Forwarding Section in the document titled

“About Disaster Recovery at https://help.zscaler.com.

The Send Trac option bypasses ZCC, allowing the user access to any destination through

direct internet access. Disable Internet Trac will cause all trac to drop at the endpoint,

preventing internet access to ZCC users.

Part of ZIA Disaster Recovery

Test Group

Zscaler recommends having at least one prole per platform designated as a DR Test Group

with a corresponding group of test users.

Table 9 ZCC App Proles Policy ZIA DR Settings

White Paper 14

ZPA Conguration

ZPA DR mode allows enrolled and authenticated users to have network-level access to mission critical

applications enabled for DR via ZCC, when the ZPA service is not accessible. Unlike ZIA, ZPA DR is

congured using both the ZCC and the ZPA Admin Portal.

ZCC Portal Conguration

1. In the ZPA Admin Portal, navigate to the Zscaler Client Connector Portal

2. Click App Proles

3. For each supported platform (Windows and macOS), edit an existing policy or create a new

one as applicable.

4. Scroll to the ZPA Disaster Recovery section and toggle Disaster Recovery service

5. Congure the ZPA Disaster Recovery settings using the table below.

Settings Status

Activation Domain Name Enter the disaster recovery domain name

Domain Public Key Upload the dr_publickey.pem le created with the Zscaler Record Generator Tool.

This key is used to validate the DNS TXT records

Part of ZPA Disaster Recovery

Test Group

Zscaler recommends having at least one prole per platform designated as a DR Test Group

with a corresponding group of test users.

Table 10 ZCC App Prole ZPA DR Settings

1. Open the portal and navigate the conguration page by clicking to Administration -> Settings

->Disaster recovery -> Settings

ZPA Portal Conguration

White Paper 15

Settings Status

Max Age for Authentication This is the set amount of time that the current end-user authentication is valid for during

Disaster Recovery Mode. The default maximum age for authentication is 14 days.

Disaster Recovery Public Key Upload the dr_publickey.pem le created with the Zscaler Record Generator Tool. This key is

used to authenticate the DNS TXT records

Disaster Recovery Domain Name Enter the disaster recovery domain name

Table 11 ZPA Disaster Recovery

2. Congure the ZPA Disaster Recovery Settings using the details in the table below.

3. Go to Administration -> Application Management -> Application Segments

4. Edit the application segment(s) that include the mission-critical applications.

5. Within the Edit Application Segment Screen, click Next to get to General Information

6. Set Disaster Recovery to Enabled and click Save

7. Go to Administration -> App Connector Management -> App Connector Groups

White Paper 16

8. Edit the App Connector Groups that serve the mission critical applications by setting

Disaster Recovery to Enabled

9. Click Save.

10. Go to Administration -> Service Edge Management -> Service Edge Groups.

11. Edit the existing Service Edge Groups or create new Service Edge Groups as applicable.

12. Set Disaster Recovery to Enabled.

13. Navigate to Administration-> Service Edge Management -> Service Edges

14. Record the public IP addresses of the PSEs that are members of the DR Enabled Service Edge Groups.

15. Validate there are DNS A records congured in the Disaster Recovery domain resolving to the public IP

address of each PSE enabled for DR.

Testing

Zscaler recommends testing Disaster Recovery as part of the initial conguration. Periodic DR testing

should be done at least twice a year as part of the organization’s existing DR Test Schedule. ZIA DR

Trac Forwarding conditions and may report problems accessing locations blocked or not allowed during

DR testing.

For ZIA, only users assigned to App Proles marked as Part of DR Testing Group will operate using the DR

trac forwarding mode.

White Paper 17

ZPA Regular Users under Test Mode

Activating Test Mode will disconnect all users connected to the PSEs and App Connectors enabled for

DR Testing. Additional PSEs and App Connectors not enabled for DR test mode must be available to

allow regular users to continue accessing applications during the test. Otherwise, any application serviced

through the DR PSEs and DR App Connectors will remain inaccessible to non-test users during the test.

ZPA Users in Test Mode

In the case of ZPA, users connecting to Application Segments, App Connectors, and PSEs marked as Part

of the DR Test Group will be able to access applications congured for DR. Applications not marked for DR

will be inaccessible during the test.

Environments must be sized and segmented appropriately for both regular cloud application access and DR

testing to avoid creating a business disruption.

Enable DR Test mode through the following process:

1. Create a DNS TXT record using the Zscaler Record Generator Tool

Generator Tool Prompt Value Notes

Signed DNS records? Yes Zscaler recommends using signed DNS records when

performing DR operations.

Create key pairs? No Copy the dr_privatekey.pem le /Program Files/Zscaler Record

Generator/Files

Disaster Recovery needs to be

congured for ZIA?

Yes If activating DR test mode for ZIA, otherwise set No

Overwrite ZCC Portal

conguration

No Zscaler recommends using the Pre-dened Destinations option that

is only congured in ZCC Portal

Disaster Recovery needs to be

congured for ZPA

Yes If activating DR test mode for ZPA, otherwise set to No

Set the disaster recovery

status for the disaster recovery

domain;

Test Only App Proles, App Segments, App Connectors and PSEs

marked as Part of DR Test Groups will enter DR Mode.

Do you want to start disaster

recovery now?

No Enter the activation date in yyyy-mm-dd format and time in UTC

using the hh-mm-ss format

Default disaster recovery

activation

No Enter the deactivation date in yyyy-mm-dd format and time in UTC

using the hh-mm-ss format

Table 12 Zscaler DNS Record Generator Settings for test mode

2. Upload the DNS TXT records to the DNS server for the disaster recovery domain name to activate

Disaster Recovery Test Mode

3. Upon DNS propagation, DR mode will be activated for users and groups congured within App

Proles enabled for both Disaster Recovery and marked as Part of ZIA / ZPA Disaster Recovery

Test Group.

White Paper 18

4. Test users should validate that access to the Mission Critical Applications (ZPA validation) and internet

sites (ZIA) can be achieved. The results of each tested application and site should be documented for

audit (pass/fail) and reviewed for changes from previous tests.

5. Instruct test users to try to access non-mission Critical Applications and sites blocked through custom

allow lists or not included within Zscaler’s predened Global Allow list and record the results of

each test.

6. Failed tests should be remediated by validating existing DR congurations. Modify congurations and

conduct additional tests until achieving the expected results.

7. Once testing is complete, create a new DNS TXT Record with a Disaster Recovery Mode (b) tag set

to o

NOTE: During DR Test Mode, any PSE and App Connector marked for participation in DR Test Group

will reboot, causing all users connected to that PSE and App Connectors to lose connectivity to the

applications serviced by those components until they reconnect to non-DR marked App Connectors and

PSEs as applicable.

Deactivating Disaster Recovery

DR mode will deactivate once the current time exceeds the end time included in the DNS TXT Record. To

deactivate DR before that time, create a new DNS TXT record using the Zscaler Record Generation Time

with the following settings.

Generator Tool Prompt Value Notes

Signed DNS records? Yes Zscaler recommends only using signed records to perform

DR operations.

Create key pairs? No Copy the dr_privatekey.pem le /Program Files/Zscaler Record

Generator/Files

Disaster Recovery needs to be

congured for ZIA?

Yes If deactivating DR test mode for ZIA, otherwise set No

Overwrite ZCC Portal

conguration

No Zscaler recommends using the Pre-dened Destinations option that

is only congured in ZCC Portal

Disaster Recovery needs to be

congured for ZPA

O If deactivating DR test mode for ZPA, otherwise set to No

Set the disaster recovery

status for the disaster recovery

domain;

Test Deactivates DR Mode

Do you want to start disaster

recovery now?

Yes Deactivation will take place upon uploading the DNS TXT record

Default disaster recovery

activation

Ignore Value is not required

Table 13 DNS settings for Test Mode DNS TXT Records

White Paper 19

User Experience during Disaster Recovery

Once DNS TXT records are uploaded ZCC, App Connectors and PSEs will detect activation and enter

DR Mode. The user experience is as follows:

ZIA Users

• Users may experience an interruption if browsing the internet

• The Internet Security Section within ZCC will display “Safe Mode” in the Service Status section

• Log entries will be created within the Notications Section of ZCC

White Paper 20

• Users may see an HTTP 403 error for blocked destinations.

ZPA Users

Once App Connectors and PSEs detect DR mode activated, they will reboot, dropping all connections.

Users may be disconnected for 30 seconds until ZCC connects to a DR-enabled PSE. From that point,

forward users will have network-level access to mission critical applications enabled for DR. The user

experience is as follows:

• Once ZCC detects DR mode the user will receive a Safe Mode popup notication.

• The Private Access section within ZCC will display “Safe Mode” in the Broker section

+1 408.533.0288 Zscaler, Inc. (HQ) • 120 Holger Way • San Jose, CA 95134 zscaler.com

About Zscaler

Zscaler (NASDAQ: ZS) accelerates digital transformation so that customers can be more agile, ecient, 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 SSE-based Zero Trust Exchange is the world’s largest inline cloud security platform. Learn

more at zscaler.com or follow us on Twitter @zscaler.

Zero Trust Exchange™, Zscaler Internet Access™,

ZIA™, Zscaler Private Access™, and ZPA™ 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.

• Log entries will be created within the Notications Section of ZCC