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
jqcommand can be used to convert the output string into a more readable CSV file.
In the above command,
jq -r '.zones | [.zone,.nameServers,.nameServers,.nameServers] | @csv' nsoutput.json
nsoutput.jsonis 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".
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.
When troubleshooting BlueCat Cloud DNS, the additional info contained in
server.log may be helpful for identifying issues. For deployment errors,
Hosted Service responded with HTTP code to find more information
on the API response from the cloud provider. Similarly, search for
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