Troubleshooting - Adaptive Applications - BlueCat Gateway - 21.2

BlueCat Distributed DDNS Administration Guide

Locale
English (United States)
Product name
BlueCat Gateway
Version
21.2

The following section outlines common problems that might occur when implementing the Distributed DDNS Adaptive Application.

How do I see the Docker volumes that have been created on a BDDS?

You can see a list of Docker volumes created on a BDDS by running the following command:
docker volume ls

How do I see the location of a Docker volume?

You can see the location of a Docker volume by running the following command:
docker volume inspect <volume_name>
For example, to view the volume location of Distributed DDNS, run the following command:
docker volume inspect ddns_config

How can I check the log files for DDNS Service on a Distributed DDNS Service Node?

You can list the directory of the log files by running the following command:
docker exec distributed_ddns ls /var/log/distributed_ddns/
You can also see the contents of a log file by running the following command:
docker exec distributed_ddns tail -f /var/log/distributed_ddns/receiver.log

How can I check DDNS Service configuration on a Distributed DDNS Service Node?

You can list the directory of the configuration files by running the following command:
docker exec distributed_ddns ls /ddns/ddns_service/etc/
You can also see the contents of the DDNS service configuration file by running the following command:
docker exec distributed_ddns cat /ddns/ddns_service/etc/ddns.yaml

How can I check the configuration of Anycast services on the Distributed DDNS Service Node?

You can list the directory of the Anycast configuration files by running the following command:
docker exec distributed_ddns ls /etc/quagga/
You can also see the contents of the Anycast service configuration file by running the following command:
  • BGP service configuration file:
    docker exec distributed_ddns cat /etc/quagga/bgpd.conf
  • OSPF service configuration file:
    docker exec distributed_ddns cat /etc/quagga/ospfd.conf
  • OSPFv3 service configuration file:
    docker exec distributed_ddns cat /etc/quagga/ospf6d.conf

How can I check the configuration of the Queue Service on the Distributed DDNS Service Node

You can list the directory of the configuration files by running the following command:
docker exec distributed_ddns ls /etc/rabbitmq/
You can also see the contents of the queue service configuration file by running the following command:
docker exec distributed_ddns cat /etc/rabbitmq/rabbitmq.conf

How can I check the logs of the Queue Service on the Distributed DDNS Service Node

You can list the directory of the log files by running the following command:
docker exec distributed_ddns ls /var/log/rabbitmq/

How can I check the configuration of all Configuration Daemons on the Distributed DDNS Data Node?

You can list the directory of the configuration files by running the following command:
docker exec <node_name> ls /daemon_run/

The configuration files of each daemon are located in the /config directory of each daemon.

How can I check the logs of all Configuration Daemons on the Distributed DDNS Data Node?

You can list the directory of the log files by running the following command:
docker exec <node_name> ls /daemon_run/

The log files of each daemon are located in the /config directory of each daemon.

How can I check the cluster configuration on the Distributed DDNS Data Node?

You can list the directory of the configuration files by running the following command:
docker exec <node_name> ls /etc/mysql/

How can I check the cluster logs on the Distributed DDNS Data Node?

You can retrieve the log files by running the following command:
docker logs -f <node_name>

The Distributed DDNS service could not start after installing the Distributed DDNS Service Node

If your Distributed DDNS Service Node is operating on Ubuntu 16, the dnsmasq service might use port 53, preventing the Distributed DDNS service from starting.

To resolve this issue, disable dnsmasq:
  1. Log in to the console of the Distributed DDNS service node.
  2. Edit the /etc/NetworkManager/NetworkManager.conf file.
  3. Comment out the following line:
    #dns=dnsmasq
  4. Reboot the service node using the following command:
    reboot
Once the proxy service node has rebooted and come back up, the DNS server might be set automatically by DHCP. Verify the configuration using the following command:
cat /etc/resolv.conf

TSIG Key list could not be loaded when adding a new zone

If your TSIG Key list could not be loaded in the Distributed DDNS Application Node, check the BlueCat Gateway log files for the following message:
ERROR - Couldn't get tsigs from BAM. Make sure you configured information to initialize connection to database !!!. Details: FATAL: no pg_hba.conf entry for host "192.168.56.106", user "bcreadonly", database "proteusdb", SSL on
FATAL: no pg_hba.conf entry for host "192.168.56.106", user "bcreadonly", database "proteusdb", SSL off

If these messages exist, log in to the Address Manager console and add a host entry to the database. For more information on adding access to the Address Manager database, refer to the Address Manager Administration Guide.

Distributed DDNS sends an update to the DNS server but the server fails to process it

If the DNS server fails to process the update, check the Distributed DDNS log files for the following message:
2019-09-22 23:26:55,220 DEBUG: Response from DNS: <Message id=39580 opCode=5 rCode=9 maxSize=0 flags=answer queries=[Query('56.168.192.in-addr.arpa', 6, 1)] additional=[<RR name=key-example-com type=TSIG class="ANY" ttl=0s auth=False>]>
2019-09-22 23:26:55,221 ERROR: 56118 Update failed by server: verified = 0, rCode = 9. No retry
If these messages exist, verify the following information:
  • Check if Distributed DDNS and DNS server are using the same key name. For example, check if the key name is not assigned to an "update-policy" of the zone or is assigned but not deployed to the DNS server.
  • Check if the secret, algorithm, and key length are the same for that key name.
  • Verify that the time on the Distributed DDNS and DNS server does not differ by more than 5 minutes.

A client sends an update to a Distributed DDNS Service Node but the node fails to update

If the Distributed DDNS Service Node fails to process the update, check the Distributed DDNS log files for the following message:
"Failed permission: Update is not allowed or denied explicitly"
If the messages exist, check the Distributed DDNS workflow configuration to see if there are any permissions configured for the updated zone. The update is denied in the following cases:
  • No permissions are configured. In this case, all DDNS updates are denied.
  • No permissions are configured that explicitly allow the resource record to be updated.
  • Permissions are configured that explicitly deny the resource record from being updated.

The Distributed DDNS Data Node container did not start after rebooting my BDDS

When you reboot your BDDS, the Distributed DDNS Data Node containers do not automatically start after the BDDS has come back up. The Distributed DDNS Data Nodes are clustered and must be restarted in a certain order to ensure that all nodes in the cluster are operating correctly.

For more information on determining the order in which Distributed DDNS Data Nodes must come up and how to restart the Distributed DDNS Data Node containers, refer to Recovering the Distributed DDNS Data Node database cluster.