Panellicense

Set up secondary DNS for Plesk with Slave DNS Manager

A Plesk box serving its own DNS is a single point of failure. Wire up a plain BIND server as a secondary nameserver with the Slave DNS Manager extension.

8 min readUpdated 2026-08-24plesk · dns · bind · slave dns manager
schema: HowToschema: FAQPageschema: BreadcrumbList

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.exe present under C:\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?+
No. It runs stock BIND with no control panel, so it costs nothing in licensing. Only the Plesk master needs a license, and adding secondaries does not change its domain count.
How many slave DNS servers can Plesk have?+
The extension accepts multiple secondaries and pushes every zone to all of them. Two is the practical minimum for redundancy; beyond three you are mostly adding transfer load to the master for little gain.
Why are my DNS zones not transferring to the slave server?+
In order of likelihood: allow-new-zones is missing on the secondary, SELinux is blocking named from writing zone files, port 953 is filtered, or the rndc secret does not match on both sides. Check named's log on the secondary first — it names the specific failure.
Can I use another Plesk server as a slave DNS server?+
Yes, but not with this extension. Slave DNS Manager targets plain BIND hosts; a second Plesk server manages its own DNS and would fight the extension for control of the zone files.
Does Slave DNS Manager work with DNSSEC?+
Signing stays on the Plesk master. The secondary transfers the signed zone as-is, so DNSSEC keeps working, but do not enable signing independently on the secondary.

Next steps

Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.