# DirectAdmin DNS Clustering: Reliable Multi-Server Setup

Source: https://srvscripts.com/guides/directadmin-dns-clustering-multi-server/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

Running two or more DirectAdmin servers usually creates two problems at once: a domain created on one server should not be creatable on another, and the nameservers customers point to should keep answering when one server is down. DirectAdmin solves both with the **Multi Server Setup** page at Admin Level, which connects panels to each other over their own API on port 2222 rather than relying on BIND zone transfers. This guide covers the configuration, the checks it enables and the pieces that still need doing by hand.

In short: Add every other server on the Multi Server Setup page with a dedicated admin account, SSL and the domain check, user check and zone transfer options enabled, then use the send-all-zones action to push existing zones.

**Short answer:** Add every other server on the Multi Server Setup page with a dedicated admin account, SSL and the domain check, user check and zone transfer options enabled, then use the send-all-zones action to push existing zones. DirectAdmin pushes full zones over its API on port 2222 rather than AXFR, so open that port between members in CSF, set `ns1` and `ns2` with `da config-set`, and register glue records so both servers actually answer for the zones.

## How the clustering works

Each server holds a list of remote servers. When a zone is created, modified or deleted locally, DirectAdmin sends the full zone to every remote entry that has zone transfer enabled, and the remote panel writes it into its own `named` as an ordinary primary zone. There is no AXFR involved, which is why the zones on every member are editable and why the setup works even when the servers sit behind different firewalls. The same connection is used, before a user or domain is created, to ask each remote server whether that name already exists.

Because the transport is the panel API, the account used must be an admin on the remote side. Create a dedicated admin on each server for this purpose rather than reusing the main admin login; if one server is compromised the credential can be revoked without touching anything else.

## Adding a server

On the first server open **Admin Level → Multi Server Setup** and add the second server’s hostname, port 2222, the dedicated admin username and its password. Enable SSL so the API traffic is encrypted, and tick the three options that matter: **Domain check**, **User check** and **Zone transfer**. Repeat on the second server pointing back at the first. With three or more servers every server needs an entry for every other, because the relationship is not transitive.

The settings are stored in `/usr/local/directadmin/data/admin/multi_server.conf`, one line per remote host. It is worth knowing the location for auditing, but edit it through the interface so the password is stored the way the panel expects.

On modern builds the admin API also allows scripting the entries. Check the API documentation for your build under `/api/` if you need to provision a fleet automatically, since the old `CMD_API_MULTI_SERVER` form endpoint is one of the legacy interfaces that has been moving to the new API set.

After saving, use the **Test connection** action on each entry. A failure here is almost always one of three things: port 2222 blocked between the servers by CSF, a self-signed panel certificate on the remote host with SSL enabled and certificate verification on, or a wrong password. In CSF, add the peer IPs to `/etc/csf/csf.allow` and restart with `csf -ra`.

## Pushing the existing zones

Adding a server only affects zones created afterwards. To send everything that already exists, use the **Send all zones** action on the Multi Server Setup page (the label differs slightly between Evolution versions). Then confirm the remote side received them:

```
ls /var/named/ | wc -l
grep -c '^zone' /etc/named.conf
```

Both counts should match on all members, allowing for zones that only exist on one server because of local-only domains.

## Making the nameservers actually redundant

Zone synchronisation is only half the job. The public NS records must name both servers, and each server must answer for the zones. Set the default nameservers used for new domains from **Admin Level → Administrator Settings**, or on the CLI:

```
da config-set ns1 ns1.example.net
da config-set ns2 ns2.example.net
```

Also register glue records at the registrar for the nameserver hostnames, and make sure `named` on each server listens on the public interface, not only on localhost. If the server runs a local Unbound resolver on port 53, as described in [Configuring Unbound as the local resolver on DirectAdmin](/guides/directadmin-unbound-resolver-https-svcb/), keep BIND on the public IP and Unbound on the loopback address so they do not fight for the port.

## Common pitfall: DNS records pointing at the wrong server

When a zone is pushed to a second server it is copied verbatim, so its A records point at the server that created it. That is correct for hosting, but it means the second server’s own IP never appears unless the customer’s account is also on that server. Problems arise when administrators try to use the DNS cluster as a poor man’s failover and expect traffic to move automatically; it does not. The cluster provides nameserver redundancy only.

A related trap is the domain check. When it is enabled and a remote server is unreachable, DirectAdmin refuses to create the domain rather than risk a duplicate. If a member is being rebuilt, temporarily untick **Domain check** for it or account creation will fail fleet-wide.

## Verify

Query each nameserver directly for a zone created after the cluster was set up:

```
dig +short @ns1.example.net example.com A
dig +short @ns2.example.net example.com A
dig +short @ns1.example.net example.com SOA
dig +short @ns2.example.net example.com SOA
```

The answers and the SOA serials should match. Then attempt to create a user on the second server with a username that already exists on the first; the panel should reject it with a message naming the remote server. Finally, review `/var/log/directadmin/system.log` on both servers for `multi_server` entries after a zone change, which confirms the push happened and how long it took.

## DirectAdmin DNS clustering at a glance

**Official documentation:** [DirectAdmin documentation](https://docs.directadmin.com/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Configuring Unbound as the local resolver and enabling HTTPS/SVCB records on DirectAdmin](https://srvscripts.com/guides/directadmin-unbound-resolver-https-svcb/) · [Issuing wildcard certificates with DNS challenges on DirectAdmin](https://srvscripts.com/guides/directadmin-wildcard-certificate-dns/) · [What changed in DirectAdmin system backups after sysbk was replaced (1.709) — and what you must add](https://srvscripts.com/guides/directadmin-system-backup-sysbk-1-709/).

## Frequently asked questions

### Does DirectAdmin DNS clustering work with cPanel or a standalone BIND server?

No. The Multi Server Setup speaks only to other DirectAdmin panels over their API. To feed zones to a non-DirectAdmin nameserver, configure BIND on the DirectAdmin server as the primary and use ordinary AXFR with `allow-transfer` and `also-notify`.

### How long does zone synchronisation take between DirectAdmin servers?

A single zone change is pushed within seconds of being saved, and the send-all-zones action for a few thousand zones typically completes in minutes; check `/var/log/directadmin/system.log` for the timing on your fleet.

### Can I undo this?

Yes. Remove the remote entries from the Multi Server Setup page on each member; zones already copied stay in `named` on the other servers until deleted, so remove any that should not remain and adjust the NS and glue records before decommissioning a nameserver.