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

Global Server Selector Administration Guide
Locale
English
Product name
BlueCat Gateway
Version
23.1

Before deploying the GSS Adaptive Application, you must define the regions that will be used with GSS and assign DNS roles to the DNS/DHCP Servers that will be used in each region.

GSS is configured with a fixed list of region names. For each application that is managed by GSS, a search order will be configured that maps client regions to a prioritized list of answer regions. 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 deploying GSS, 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. 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.

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
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

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.

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.

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.

For more information, refer to Adding the Allow Dynamic Updates DNS Deployment Option and Adding the Allow Zone Transfer DNS Deployment Option.

NTP configuration

To enable TSIG authentication, NTP or a similar protocol must be used to synchronize time between the GSS servers and BlueCat DNS/DHCP Servers.