- When assigning client regions to DNS Cache servers or IP address ranges, where the region represents the location of the clients.
- When assigning a region to answers, where the region represents the location of the service instance. This is an answer region.
- When assigning GSS servers to regions, where the region represents a cluster of GSS servers that share the current availability status of service instances and update linked client regions. This is a health-check region.
Within these regions, you can configure sub-regions. Sub-regions are used when assigning regions to IP address ranges and represent the location of both clients and service instances. Sub-regions affect the order of responses returned to clients.
When a region or sub-region is linked to an IP address range, this information is also used to automatically select answer regions when adding a new answer to an application configuration in GSS.
- As a health-check region where GSS servers are deployed.
- As a client region that will be configured on DNS servers.
- As an answer region that contains service instances for applications managed by GSS.
The following image displays an example GSS region set:
GSS DNS zones
The GSS configuration and state is stored in DNS. By default, a single global zone,
gss.bluecat
, stores all GSS configuration. The DNS server with
the Primary role for this zone should be located in a central data-center that is
accessible from all deployed instances of GSS. All GSS data should be resolvable by
querying this server.
gss.bluecat
zone in which the GSS application resides. This can cause problems where you would
like to restrict the access that GSS users have to the global zone that GSS uses.
When configuring an application in GSS, you can create a separate configuration zone
within Address Manager, allowing you to limit user access to specific zones while
ensuring that users still have the ability to work with GSS. When limiting access to
specific zones, GSS uses the following zone to map the GSS configuration data in the
separate zone:config_zone.gss.bluecat
For more information, refer to Configuring an application in GSS.
<region-name>.rpz.gss.bluecat
<region-name>.status.gss.bluecat
Default.status.gss.bluecat
If GSS is used primarily for failover, the Default region is required to switch to a backup server if a primary server fails. This can work in external authoritative zones. However, if GSS is only used for internal zones and every client IP address is mapped to a client region, the Default region is not required.
The following image displays an example of how regions can be mapped to DNS roles:
DNS roles
DNS servers are configured to use a Response Policy zone to provide answers for a specific Client region. To use a Response Policy zone, the DNS server must be authoritative for that RPZ zone by having either a Primary, Hidden Primary, Secondary or Stealth Secondary role.
For a regional GSS instance to update responses when the central infrastructure is unavailable, the server with the DNS Primary role for the regional health-check zone and RPZ zones must be in the same region.
In a typical implementation of GSS, you can assign the Primary role for regional health-check and RPZ zones to a regional DNS cache server. When you are installing the GSS application, the installation workflow allows you to assign the DNS roles for the health-check zones. For more information, refer to Installing GSS configurations in Address Manager.
DNS options
You must create a TSIG key in Address Manager for use by the GSS Adaptive Application. When configuring the TSIG key, select hmac-sha512 as the algorithm. When you are installing the GSS application, the installation workflow allows you to create a TSIG Key in Address Manager. For more information, refer to Installing GSS configurations in Address Manager.
If you use GSS with views, GSS will use the key you create as a seed and create a separate TSIG key for each view.
BlueCat DNS/DHCP Servers must be configured to allow GSS to dynamically update DNS information. Add the Primary GSS TSIG key to an Allow Dynamic Updates option at the view level so that GSS can update default responses in any zone, including updating GSS data.
BlueCat DNS/DHCP Servers must also be configured to allow GSS to use zone transfer to
enumerate GSS zones. Add the GSS TSIG key to an Allow Zone
Transfer option at the view level. This ensures that GSS can both
update the IP address of managed applications in the application zone and update GSS
data stored in the gss.bluecat
zone.
The Allow Dynamic Updates and Allow Zone Transfer options can be configured from the GSS application installation workflow. For more information, refer to Installing GSS configurations in Address Manager.