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.
- 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.
- 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. 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.
The following image displays an example of how regions can be mapped to 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.
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
For more information, refer to Adding the Allow Dynamic Updates DNS Deployment Option and Adding the Allow Zone Transfer DNS Deployment Option.
To enable TSIG authentication, NTP or a similar protocol must be used to synchronize time between the GSS servers and BlueCat DNS/DHCP Servers.