• Secure Mobile Access 12.4
• About This Guide
• CMS Configuration
  • Introduction to CMS
    • Overview
    • CMS Deployment Options
    • What’s New in This Release
      • Global Policy Settings
      • CMS Alerts Logging
    • Central Management Server
    • Central Management Console
    • Managed Appliances
    • Licensing CMS
    • Central User Licenses
    • Global Traffic Optimizer
    • FIPS and CMS
    • Getting Started in Five Steps
  • Installing and Configuring the Central Management Server
    • Overview
    • Kernel based Virtual Machine
    • Supported Platforms for CMS with Global HA
    • Hardware Resource Requirements
    • Installation Files
    • Setting Up a CMS
  • Configuring Appliances for Central Management
    • Overview
    • Firmware Compatibility with the CMS
    • Enabling Central Management on SMA Appliance
    • Registering an SMA Appliance with the CMS
    • Previously Configured Appliances
  • Using the Management Console Menus
    • Overview
    • Dashboard
      • Alerts
      • Appliances Pane
      • Appliance Load
      • Central License Usage Pane
      • About Pane
    • Management Server
      • Alerts
        • View Alerts
        • Configure Alerts
        • Notification
      • Configure
        • Central Management Settings
        • CMS Address Pool
        • Licensing
        • Administrators
          • General Settings
        • Network Settings
        • SSL Settings
        • Services
          • Manage SSH settings from CMS
      • Monitor
        • Configure the logging setting for Managed appliances
      • Maintain
    • Managed Appliances
      • Add/Remove
      • Configure
        • Overview
        • Configuring the Managed Appliances
          • Define Policy
          • Synchronize
        • Support multiple policies with CMS and shared licensing
          • Applying authentication servers to specific appliance
          • Applying SMTP configuration service to specific appliance
          • Applying SMS service to specific appliance
          • Applying realms to a subset of appliance
          • Assign rules to a subset of appliances
          • Support multiple GTO services
      • Monitor
        • User Sessions
        • Reports
        • Health
      • Maintain
  • Central User Licensing
    • Overview
    • How Central User Licenses Work
      • Central Spike User Licenses
      • Central Email Licenses
      • Perpetual Pooled Licenses
    • Enabling Central User Licensing
    • Getting Started with Central User Licensing
      • Setting Up CMS to Use Central User Licenses
      • Setting up CMS for Centralized Appliance Configuration and Management
      • Resetting a CMS License
  • Global High Availability
    • High Availability of the VPN Service
    • High Availability of the CMS
    • Disaster Recovery for the VPN Service
  • Alerts and SNMP
    • Overview
    • Pre-Configured Alerts
    • Configuring SNMP
  • Capture Advanced Threat Protection
    • Enabling Capture ATP
    • File Options
    • Web Services
    • Advanced Settings
  • Central FIPS Licensing
• Global High Availablity
  • Introduction to Global HA and GTO
  • Planning GTO Deployment
    • Choosing a Deployment Model
    • Minimizing Configuration Differences
    • GTO Service Names and DNS Delegations
    • Provisioning Certificates
      • Let's Encrypt
      • Adding Certificates to SMA Appliances
      • Generating a Certificate Signing Request (CSR)
      • Importing SSL Certificates
  • Setting up GTO
    • Setting up the CMS and SMA appliances
    • Enabling GTO service for managed appliances with the CMS
    • Setting up a Basic GTO Service
    • Monitoring and Configuring GTO
    • Defining the Central Policy
  • Extending GTO Deployment
    • Enabling Cached Credentials
    • Additional Deployment Notes
• SonicWall Support
  • About This Document

GTO Service Names and DNS Delegations

To establish a GTO service, you must choose a GTO service name and establish DNS delegations.

Choosing a GTO Service Name

The GTO service name is a delegated DNS zone, which means you must control the parent zone and make a delegation from it to one or more SMA appliances under the GTO service.

If your organization controls the example.com DNS zone, the access.example.com or vpn.example.com could be appropriate GTO service names.

Establishing the GTO Service Name Delegations in DNS

A GTO service name delegation is a DNS subzone delegation. It requires NS records that identify the authoritative server names for the subzone, and corresponding glue-A record that provides IP addresses for those authoritative server names.

DNS delegations must be created for the following components on each of the managed appliances:

• Primary GTO service
• Custom FQDN
• Custom Workplace Sites
• Outlook Anywhere
• Active Sync

The authoritative servers themselves are SMA appliances that are part of the GTO service and are identified by their public IP addresses and the NS record names in the following format:

<DNSname>.ns.<GTOserviceName>

For example, the following two DNS records in the zone configuration of example.com could establish a delegation for the GTO service and SMA appliance described above:

access.example.com. 86400 IN NS node1.ns.access.example.com

node1.ns.access.example.com. 86400 IN A xxx.xxx.xx.xx

In a typical GTO deployment with multiple SMA appliances, it is important to establish at least two such delegations. This ensures that the GTO service remains available if any one the SMA appliances is brought down for maintenance (or a network outage).

At least one authoritative server (SMA appliance) must be running at any given moment. Otherwise, users will not be able to connect.

Additional authoritative servers can provide redundancy and improved performance for some users. You should limit GTO service delegations to about three. Ideally, they should be geographically distributed.