Preparing the DNS architecture for the GSS Adaptive Application - Adaptive Applications - BlueCat Gateway - 24.1

Global Server Selector Administration Guide

ft:locale
en-US
Product name
BlueCat Gateway
Version
24.1
GSS is configured with a fixed list of region names. Each application that is managed by GSS is linked to a search order. The search order enables GSS to map client regions to the closest available answer region. Region names are used in the following scenarios:
  • 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.

Regions are used for the following three purposes:
  1. As a health-check region where GSS servers are deployed.
  2. As a client region that will be configured on DNS servers.
  3. 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.

All users of GSS must have full access to the global 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.

For each Client region, GSS uses the following separate Response Policy zone (RPZ):
<region-name>.rpz.gss.bluecat
For each Health check region, GSS uses the following separate zone to record the status of answers:
<region-name>.status.gss.bluecat
(Optional) All GSS deployments should include one health-check region that is the Default region. GSS instances in the Default region update the Default response that is used when no client region response is available. The status zone for the Default region is as follows:
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.