Out of the box, Plesk runs BIND on the same machine as Apache, Postfix, and MariaDB. Every customer zone is authoritative on exactly one host. Reboot that host for a kernel update and, once the TTL expires, every domain on it stops resolving — mail included.
The fix is a second authoritative nameserver on a different box, and Plesk's official tool for that is the Slave DNS Manager extension. It talks to a plain BIND server over rndc, creates and deletes zones there as you create and delete domains in Plesk, and requires no panel license on the secondary. This walks through the whole build: BIND on the secondary, the rndc key, the Plesk side, verification, and the four ways it usually breaks.
What the extension actually does
Slave DNS Manager registers itself as a Plesk custom DNS backend. Whenever the DNS
subsystem changes — a domain added, a record edited, a subscription removed — the extension
opens a control connection to each registered secondary on TCP 953 and issues the matching
rndc command: addzone, refresh, or delzone. The secondary then pulls the zone from
the Plesk server over TCP 53 in a normal AXFR, and serves it as a slave.
Registering a secondary also adds its IP to the master's zone transfer allowlist automatically, so you do not need to hand-edit the transfer restrictions template under Tools & Settings » DNS Settings. The extension owns that entry.
This is a different architecture from a cPanel DNS cluster, where each node runs a licensed cPanel DNSONLY image and the cluster API pushes complete zone files. Here the secondary is a stock BIND install with no panel on it at all — cheaper to run, but with no UI of its own and no ability to accept edits.
Before you start
- A separate server. A VPS with 1 vCPU and 1 GB RAM handles tens of thousands of zones; BIND slaves are cheap. Put it with a different provider or at least a different datacentre, otherwise you have bought yourself nothing.
- Linux and BIND only. The extension speaks rndc. Microsoft DNS is not supported, and
on Plesk for Windows the extension needs
rndc.exepresent underC:\Program Files (x86)\Plesk\dns\bin\or the install fails outright. - No NAT in the way. If your Plesk server sits behind NAT, the secondary must live outside it. Zone transfer and NOTIFY both need direct reachability.
- One DNS extension at a time. Slave DNS Manager, Amazon Route 53, and DigitalOcean DNS all claim the same custom-backend hook. Installing two of them breaks zone management.
Build the secondary server
Install BIND
On Debian or Ubuntu:
apt-get install -y bind9 bind9-utils
On AlmaLinux or Rocky:
dnf install -y bind bind-utils
systemctl enable --now named
Generate the rndc key
Generate on the secondary, with an explicit name that identifies the master. Using the Plesk server's IP in the key name keeps things readable once you have several masters pointing at one secondary:
tsig-keygen -a hmac-sha256 rndc-key-198.51.100.10
That prints a key { ... } block. Keep the base64 secret — you paste the same string into
Plesk in a moment.
Configure named
Three things must be present on the secondary: allow-new-zones, the key, and a controls
block that accepts connections from the Plesk IP. On AlmaLinux and Rocky this all goes in
/etc/named.conf; on Debian and Ubuntu put the option in /etc/bind/named.conf.options
and the rest in /etc/bind/named.conf.local.
options {
allow-new-zones yes;
};
key "rndc-key-198.51.100.10" {
algorithm hmac-sha256;
secret "YTQ2OGZiY2E4MDliMTY5OThkOGYyYw==";
};
controls {
inet * port 953 allow { 198.51.100.10; 127.0.0.1; } keys { "rndc-key-198.51.100.10"; };
};
Check and reload:
named-checkconf
systemctl restart named # bind9 on Debian/Ubuntu
allow-new-zones yes is the load-bearing line. Without it rndc addzone is refused and
zones never appear, no matter how healthy the control connection looks.
Let named write its zone directory
addzone writes both the new-zone database and the transferred zone files, so the BIND
user needs write access to the zone directory. On AlmaLinux and Rocky that means the
SELinux boolean, not just filesystem permissions:
setsebool -P named_write_master_zones 1
If you run BIND in a chroot, grant group write on both /var/named and
/var/named/chroot/var/named. Skipping this is the single most common cause of
"connection to remote host closed" and silently missing zones.
Open the firewall
Two ports, two directions:
firewall-cmd --permanent --add-service=dns
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.10" port port="953" protocol="tcp" accept'
firewall-cmd --reload
Port 53 must be open to the world on TCP and UDP — that is the service you are building. Port 953 must be open only to the Plesk server's IP. An rndc control channel exposed to the internet is a remote reconfiguration interface for your DNS.
Register the secondary in Plesk
On the Plesk server, go to Extensions » Extensions Catalog, search for Slave DNS Manager, and install it. Then open Extensions » Slave DNS Manager » Add Slave DNS Server and supply:
- the secondary's IP address,
- the key name exactly as written in
named.conf(rndc-key-198.51.100.10), - the base64 secret.
Save. Plesk validates the control connection immediately — a green entry means rndc authenticated. Existing zones are pushed on the extension's next sync; new domains propagate as they are created.
Verify it works
Create a throwaway domain in Plesk, then query the secondary directly:
dig @203.0.113.20 example.com SOA +norecurse
You want an authoritative answer with the aa flag set and the same serial the Plesk
server reports. On the secondary you can confirm the zone landed:
rndc zonestatus example.com
Then delegate. Register both hostnames as glue records at your registrar, point the domain's NS records at them, and set the pair as the default in Tools & Settings » DNS Settings so every new subscription inherits them.
The four failure modes
Zones only appear after a manual reload. A known extension behaviour: addzone
sometimes does not trigger NOTIFY, so the secondary knows about the zone but never fetches
it. rndc reload on the Plesk server kicks the transfer. If you hit this repeatedly, treat
it as a signal that NOTIFY is not reaching the secondary — usually a firewall dropping
inbound UDP 53 on the secondary from the master.
"Invalid IP address: zone may fail to transfer to slaves." Plesk raises this when a zone contains a record whose target does not resolve to a usable address. Fix the record; the zone as a whole is being rejected, not just that entry.
Key mismatch. The secret in named.conf and the secret in Plesk must be byte-identical,
and on Debian the copy in /etc/bind/rndc.key must match too. A trailing newline pasted
into the Plesk field is enough to break authentication.
Nothing syncs after a Plesk repair. plesk repair dns rewrites BIND configuration on
the master and can clear the transfer allowlist. Re-open the extension and confirm the
secondary is still listed — see the other side effects in the
Plesk repair utility reference.
Does the secondary DNS server need a Plesk license?+
How many slave DNS servers can Plesk have?+
Why are my DNS zones not transferring to the slave server?+
Can I use another Plesk server as a slave DNS server?+
Does Slave DNS Manager work with DNSSEC?+
Next steps
- Plesk repair utility commands —
plesk repair dnsis the first thing to run when the master's own BIND config drifts. - Set up the Plesk Firewall extension — scope 953 and the rest of your admin ports properly.
- Plesk license tiers explained — what a Plesk license covers, and why secondaries stay outside it.