Skip to content

Known issues

Dynamic DNS updates refused after a node swap or removal (TSIG)

Section titled “Dynamic DNS updates refused after a node swap or removal (TSIG)”

Applies to: DTM 1.0.x clusters with require_tsig: true that use dynamic DNS.

After a rolling upgrade or after removing a node, a node that joins later may not receive TSIG keys that were last saved by the removed node. Dynamic DNS updates that reach that node with one of those keys are refused. Updates are never accepted without a valid key.

To check: on a cluster node, look in the service journal for a tsig_keys_unverifiable line at start-up, or a sig-gate refused line during replication.

To fix, do this before you remove or replace any more nodes: on a node that still holds the key (one that lists it in GET /api/v1/tsig-keys), send PUT /api/v1/tsig-keys/{name} with an empty body {}. This saves the key again under a current node, keeps its secret and zone bindings, and needs no change on your DNS clients. Do not delete and recreate the key while any node still holds it, because that issues a new secret and breaks every client using it.

If no remaining node holds the key, its secret cannot be recovered. Create the key again with a new secret and update every client that uses it.

Uploaded TLS certificate not served by nodes added after a node swap or removal

Section titled “Uploaded TLS certificate not served by nodes added after a node swap or removal”

Applies to: DTM 1.0.x clusters that serve a certificate uploaded with PUT /api/v1/config/tls-certificate.

After a rolling upgrade or after removing a node, a node that joins later may not receive the uploaded certificate if the node that accepted the upload has been removed. That node keeps presenting its boot-time certificate, so clients that validate the cluster certificate are refused by it. An unverified certificate is never installed.

To check: send GET /api/v1/config/tls-certificate to each node. An affected node reports no configured certificate, or a fingerprint that differs from the other nodes. Its service journal shows full-state skipping TLS bundle from <node> naming the removed node.

To fix: upload the certificate and private key again with PUT /api/v1/config/tls-certificate, from any current node. The same certificate and key are accepted, and every node, including new ones, installs it with no restart.

If you removed a node because it was compromised, upload a new certificate with a new private key instead.