Configure and Retire WHM DNS Cluster Links Safely

WHM DNS clustering links authorized servers to share zone changes. Enabling the switch alone does not create a working cluster. Plan the publishing direction, credentials, authoritative endpoints and recovery before linking production servers.

Prepare both ends

Use maintained, compatible cPanel & WHM or DNSOnly installations and authorized administrative access. Preserve each server’s zone/configuration state privately. Confirm that matching zone names do not contain conflicting legitimate data. DNSSEC-signed domains require PowerDNS on every cPanel cluster member.

Use verified HTTPS WHM, not the old plaintext port-2086 example. Determine the intended root/reseller management scope and required permissions. Do not grant all privileges merely to expose a screen.

Enable and add the intended peer

1. Open Clusters > DNS Cluster under the intended management identity and enable clustering where required.
2. Choose the backend type and Configure. Supply the verified remote DNS host and authorized remote username.
3. Use the remote server’s WHM API token with the DNS Clustering ACL and appropriate restrictions. It is not an SSH private key; do not paste keys or tokens into public tickets/screenshots.
4. Decide whether reverse trust is needed. The documented automatic reverse relationship uses Standalone on the remote side; it is not automatically symmetric synchronization.
5. Choose role and initial synchronization deliberately. Synchronize combined with Synchronize Zones Immediately can pull all remote zones; inventory conflicts before selecting it.
6. Submit, review status and verify the intended zone on each endpoint before adding more peers.

Understand roles and failure handling

Standalone accepts applicable newer-zone changes without signaling modifications onward. Synchronize reconciles changes using zone freshness. Write-only pushes without the same conflict checks and can overwrite newer data. These are directional link behaviors; avoid multiple uncontrolled writers to the same zone.

Set failure thresholds and notifications according to the actual operational design rather than assuming defaults prove health. A member disabled after failed dnsadmin commands requires review and manual reenabling; an extended outage can require resynchronization. Debug logging is optional and may contain sensitive operational data, so do not enable it indefinitely without a reason.

Remove or replace a peer carefully

Before disabling/removing a member, review vendor removal behavior, remaining zone copies, delegation and rollback. Disable clustering on the retired server as appropriate, remove its configured links from remaining members and verify surviving records. cPanel warns that removing a member can affect records remaining in the cluster; do not treat removal as harmless housekeeping. Revoke unneeded tokens and retain required recovery copies.

Test record publication, serial/data consistency and authorized DNS reachability separately from API connectivity. Neither a status icon nor two reachable IPs establishes independent fault tolerance.

References: WHM cluster lifecycle and roles and cluster topology guidance.

Reviewed October 16, 2026. Consolidated the matching setup guide; no API token, cluster link, synchronization or removal operation was executed.