DNS Clustering
DNS clustering keeps every zone this server hosts in sync with other nameservers, the way cPanel's DNS cluster or DirectAdmin's multi-server DNS do. When it is enabled, every zone change - a website added or removed, a record edited in the user panel or the admin zone editor, a dynamic-DNS update, a DKIM or TLSA record written by the mail stack - is pushed to every registered peer within seconds, and a nightly reconciliation pushes everything again and prunes what no longer exists.
Two kinds of peer are supported:
| Peer type | What it is | How zones arrive there |
|---|---|---|
| HiTechCloud Panel (recommended) | Another HiTechCloud server: a full server, or one installed with the DNS-only role that hosts no websites. | Pushed to the peer's admin panel on port 2087 (POST /api/dns/cluster/sync), authenticated with an HMAC over the peer's cluster token. The peer serves the zone from its own BIND, either as a master copy of the zone file or as a slave that transfers it from this server (AXFR + NOTIFY). |
| Third-party DNS provider | A cPanel/WHM server (typically a WHM DNS-only node), a DirectAdmin server, a Plesk server, or a Cloudflare account. | The zone's records are mirrored through the provider's own API. The provider keeps its own SOA and apex NS records. |
Use HiTechCloud Panel DNS - the built-in BIND cluster - for your nameservers: install HiTechCloud on two or more small servers, point ns1/ns2 at them, and add each as a peer. It needs no third-party account, keeps DNSSEC signing on this server, and supports both copy and AXFR modes.
Third-party providers are supported for migration and coexistence: keeping a WHM DNS-only node current while accounts move off cPanel, keeping zones at Cloudflare because the registrar already points there, or running a Plesk box's DNS alongside. They are not the recommended primary nameserver setup.
Requirements​
- The admin panel (port 2087) reachable from this server on every HiTechCloud peer; BIND9 installed there (the native installer does this; the dns-only role is enough).
jqon this server (installed byINSTALL.sh).- For third-party providers, an API credential with permission to manage DNS zones (see each provider below).
Enabling clustering​
HiTechAdmin > Domains > DNS Cluster > Enable DNS Clustering, or:
hitechcloudcli dns-cluster enable
Enabling generates this server's cluster token (shown on the page and by hitechcloudcli dns-cluster token), installs the nightly reconciliation cron (/etc/cron.d/hitechcloud-dns-cluster, hour configurable on the page), and writes the allow-transfer / also-notify entries BIND needs for slave-mode peers.
The page has three parts:
- This server - the URL and token a master needs in order to push zones here. A DNS-only server only ever hands these out; it has no peers of its own.
- Cluster settings - the server's role (master or DNS-only), whether the local BIND stays authoritative when third-party providers are mirrored, and the hour of the nightly reconciliation.
- Peers and DNS providers - the table of destinations with, per peer: type, mode, enabled, last sync, last success, zones pushed, and the last error. Each row has Test, Sync, Enable/Disable and Remove; Sync all now pushes every zone to every peer in the background.
The configuration lives in /etc/hitechcloud/bind9/cluster.json (mode 0600 - it holds the credentials); the status table in /etc/hitechcloud/bind9/cluster-status.json; the push log in /var/log/hitechcloud/dns-cluster.log.
Adding a HiTechCloud peer​
On the peer (the server that will receive zones):
hitechcloudcli dns-cluster enable # prints the peer's token
On this server, on the DNS Cluster page choose HiTechCloud Panel, enter a name, the peer URL (https://ns2.example.com:2087), the token, and a mode; or:
hitechcloudcli dns-cluster add-peer ns2 https://ns2.example.com:2087 <token> --mode copy
hitechcloudcli dns-cluster add-peer ns3 https://203.0.113.3:2087 <token> --mode slave --ip 203.0.113.3
| Mode | What happens | When to use |
|---|---|---|
| copy (default) | The whole zone file is sent; the peer stores it under its BIND directory (.../hitechcloud/cluster/db.<zone>) and serves it as a master zone of its own. | Simplest; works through NAT and firewalls that block port 53 TCP between the servers; the peer keeps serving even if this server is down for days. |
| slave | The peer registers the zone as type slave with this server as master. This server adds the peer's IP to allow-transfer and also-notify, so BIND notifies the peer and it transfers the zone (AXFR). | Classic primary/secondary; the peer's copy is always what BIND itself transferred, DNSSEC signatures included. Needs port 53 TCP open from the peer to this server. |
A peer with a self-signed certificate on 2087 can be added with Accept a self-signed certificate (--insecure): every request is still HMAC-signed, only the certificate check is skipped. Only these zones (--zones a.com,*.b.net) limits a peer to a subset.
After saving, every existing zone is pushed to the new peer in the background. The peer never overwrites a zone it hosts itself: if the same domain exists as a website on both servers the push is refused and shows in the Last error column.
Zones received from peers are listed on the peer with hitechcloudcli dns-cluster received.
Adding a third-party DNS provider​
Every provider runs in mirror mode: on each push the zone's A, AAAA, CNAME, MX, TXT, SRV, CAA, NS (non-apex) and PTR records are compared with what the provider holds and the difference is applied - records removed here are removed there. SOA, apex NS and DNSSEC records are left to the provider. Tick Create the zone at the provider when it does not exist (default) to have missing zones created; untick it to only update zones that already exist there.
cPanel / WHM​
Use a WHM API token (WHM > Development > Manage API Tokens) for root or a reseller that owns the zones. Calls used: listzones, dumpzone, adddns, addzonerecord, removezonerecord, removezone (WHM API 1).
hitechcloudcli dns-cluster add-provider cpanel whm-dns --url https://whm.example.com:2087 --user root --token <api token>
A WHM DNS-only server is the usual target; a full cPanel server works the same way.
DirectAdmin​
Use a login key (Admin > Login Keys) for an admin user with DNS access. Calls used: CMD_API_DNS_ADMIN (create/delete/exists) and CMD_API_DNS_CONTROL (add/select records), JSON output.
hitechcloudcli dns-cluster add-provider directadmin da-dns --url https://da.example.com:2222 --user admin --token <login key>
Plesk​
Use a Plesk API key (plesk bin secret_key --create or Tools & Settings > API keys). Calls used: REST API v2 /api/v2/domains and /api/v2/dns/records. A zone that does not exist is created as a domain with no hosting.
hitechcloudcli dns-cluster add-provider plesk plesk-dns --url https://plesk.example.com:8443 --token <api key>
Cloudflare​
Use an API token with Zone:Read and DNS:Edit on the zones (and Zone:Edit plus the Account ID to create zones). Calls used: API v4 /zones and /zones/{id}/dns_records. Records are created un-proxied (grey cloud).
hitechcloudcli dns-cluster add-provider cloudflare cf --token <api token> --account-id <account id>
hitechcloudcli dns-cluster add-provider cloudflare cf --token <api token> --no-create-zones --zones example.com
Testing, syncing and status​
hitechcloudcli dns-cluster list # peers
hitechcloudcli dns-cluster test ns2 # credentials and reachability
hitechcloudcli dns-cluster sync example.com # push one zone (what the panel runs after every change)
hitechcloudcli dns-cluster sync --all # push everything
hitechcloudcli dns-cluster sync --all --peer cf
hitechcloudcli dns-cluster status # per-peer last sync / last error
hitechcloudcli dns-cluster reconcile # what the nightly cron runs
reconcile pushes every zone and then tells each HiTechCloud peer the full list of zones this server holds, so the peer removes copies received from this server that no longer exist here.
How the push is triggered​
Every path that writes a zone ends in a call to hitechcloudcli dns-cluster sync <zone>, run in the background so no request waits on a remote server:
hitechcloudcli native-dns add|delete|set-address|publish-dkim|tlsa|bimi|...(native stack), anddomains-dnson the container stack;- the user panel's DNS zone editor, dynamic DNS and domain API;
- the admin panel's zone editor and
POST /api/domains/{domain}/dns.
The sync is skipped in a fraction of a millisecond when clustering is disabled.
Peer API​
A HiTechCloud peer exposes, on its admin port:
| Endpoint | Purpose |
|---|---|
GET /api/dns/cluster/ping | Verifies the signature; answers the peer's role and version. |
GET /api/dns/cluster/zones | The zones the peer holds on behalf of masters. |
POST /api/dns/cluster/sync | {"action":"upsert","zone":"...","mode":"copy","content":"..."}, {"action":"upsert","mode":"slave","master":"<ip>"}, {"action":"delete","zone":"..."} or {"action":"reconcile","zones":[...]}. |
Requests carry X-HiTechCloud-Timestamp (Unix seconds, accepted within 5 minutes) and X-HiTechCloud-Signature: sha256=<hex HMAC-SHA256(token, "<timestamp>.<body>")>. These endpoints work whether or not the JSON REST API is enabled - a DNS-only peer has no API users to issue tokens to. Rotating the token on the page (or hitechcloudcli dns-cluster token --rotate) invalidates every master that pushes here until it is updated.
Legacy slave list​
The Legacy slave nameservers section keeps the earlier mechanism: plain BIND slaves added by IP, reached over rndc or SSH, with their IPs in allow-transfer/also-notify. New setups should add the server as a HiTechCloud peer in slave mode instead, which does the same and adds status reporting and automatic zone registration.