Troubleshooting BlueCat Cloud DNS - BlueCat Integrity - 9.4.0

Address Manager Administration Guide
Locale
English
Product name
BlueCat Integrity
Version
9.4.0

The following section describes BlueCat Cloud DNS behaviour and common errors that may occur during configuration of the service.

BlueCat Cloud DNS deployment failures

BlueCat Cloud DNS server deployment failures are handled differently than BlueCat DNS/DHCP Server deployment failures. If any invalid zones are present in a deployment to a BlueCat DNS/DHCP Server, the deployment will fail and no updates will be made to the BlueCat DNS/DHCP Server, even if other valid zones were included in the deployment. For BlueCat Cloud DNS, deployment is processed on a best effort basis - invalid zones will be dropped by the cloud provider, but other valid zones will still be processed and added to the BlueCat Cloud DNS environment. If this occurs, Address Manager will indicate that the deployment has failed, but the deployment event payload will contain more precise details in JSON format that indicate which zones were successful and which failed.

Deployment event payloads

After processing a BlueCat Cloud DNS server deployment, the deployment event payload will contain a complete list of all zones hosted in the cloud DNS environment and their associated name server assignments in JSON format. If a deployment failure occurs, the payload will also contain a list of errors along with the list of successfully deployed zones. For information on how to view deployment events, refer to Viewing system events.
Tip: When a large number of zones are deployed, the JSON payload (under Task Details) of the Event Summary for the deployment may be difficult to read, due to a known UI display issue affecting larger output strings. To mitigate this issue, the following jq command can be used to convert the output string into a more readable CSV file. 
jq -r '.zones[] | [.zone,.nameServers[0],.nameServers[1],.nameServers[2]] | @csv' nsoutput.json
In the above command, nsoutput.json is a file containing the Task Details payload string.

Deployments to BlueCat Cloud DNS server take a long time

Deploying to the BlueCat Cloud DNS environment entails multiple internal API calls to the cloud DNS provider. As Address Manager retrieves zone states from the cloud DNS provider for each deployment, the time to process deployment will be longer when a larger number of zones is deployed. When deploying, there may be a short period where zones become visible in the cloud DNS environment, but the deployment appears to still be in progress in Address Manager. This is normal, as Address Manager issues additional configuration API calls after the calls that initially create zones in the cloud DNS environment. The deployment status will be updated once this process is complete.

For special circumstances where customers are deploying a large number of zones (i.e. 3000+), the API rate limit for the cloud provider can be increased to facilitate faster deployment. For more information, refer to KI-017984 on the BlueCat Customer Care portal.

Accidental deployment to primary before secondary

When deploying zones to the cloud environment for the first time, DNS must be deployed on the secondary (BlueCat Cloud DNS) server first to ensure that Address Manager is provided the necessary NS records to update the primary (BlueCat DNS/DHCP Server) afterwards. If the user accidentally deploys DNS on the primary before the secondary, Address Manager will deploy with a warning of "one or more zones have no nameservers". server.log can be used to specifically identify zones with no name servers, as detailed in Advanced troubleshooting below. To fix zones with this error, remove the primary Deployment Role from the zones and deploy to the primary to clear the faulty zone configuration. Once you have cleared the faulty zone configuration on the primary, add the primary Deployment Role back to the zones, deploy to the secondary (BlueCat Cloud DNS server) first, then deploy to the primary (BlueCat DNS/DHCP server).

Change of published interface IP address associated with DNS Deployment Role

If the published interface IP address associated with a primary DNS Deployment role is modified, the Address Manager server must be restarted before deploying to the primary and associated secondaries. Refer to KI-025343 on the Customer Care portal for instructions on restarting Address Manager. BlueCat recommends restarting the Address Manager server during a scheduled maintenance window in order to avoid service outages.

Change of primary DNS Deployment Role server interface

If a primary DNS Deployment Role server interface changes, associated secondary DNS Deployment Roles must be updated accordingly. For example, if a Hidden Primary DNS Deployment Role is moved from one BlueCat DNS/DHCP Server to another BlueCat DNS/DHCP Server with a different published IP address, associated Secondary DNS Deployment Roles must be updated manually with the new IP address for zone transfers. If Secondary DNS Deployment Roles are not updated with the new zone transfer interface, the change will not be propagated to the cloud DNS provider.

Advanced troubleshooting

When troubleshooting BlueCat Cloud DNS, the additional info contained in server.log may be helpful for identifying issues. For deployment errors, search for Hosted Service responded with HTTP code to find more information on the API response from the cloud provider. Similarly, search for Nameservers not found for zone to identify zones that are invalid due to incorrectly deploying to the primary before the secondary. Users can also enable debug logging before deployment to view the differential deployment data in server.log. For information on how to download and view log files, refer to Viewing Address Manager logs