Deploying slave DNS servers for Plesk

The aim is to set up one or more secondary (Slavic) DNS servers, automatically synchronized with a Plesk master DNS.
This architecture improves resiliencethe DNS propagation speedthe simplicityand the overall reliability of your hosting infrastructure.

This procedure is applied when you subscribe to the DNS slave management option via theLRob outsourcing offer. It will give you all the prerequisites and explain the procedure and system in place in this context.

Prerequisites

Hardware and architecture

  • A VPS 1 to 2 vCores and 1 to 2 GB RAM are more than enough (excluding massive traffic: >1M requests/hour).
  • 2 to 3 servers slave DNS are recommended for redundancy.
  • Compatible ARM64 or x86_64.
  • Recommended system : Debian - stable, lightweight, widely supported.
  • Each slave server must be :
    • Hosted on a network / separate supplier (different subnet).
    • Accessible in IPv4 and IPv6each with its own Dedicated IP.
    • With a hostname unique and correct.
    • With a rDNS (reverse DNS) corresponding to its hostname.

Naming and domain

  • Dedicate a infrastructure sector for your DNS servers, for example :
    example.net
  • Declare the glue records IPv4 and IPv6 with your domain registry :
    Example: ns1.example.net, ns2.example.net, ns3.example.net
  • Define these glue records as DNS servers for your domain.

These records are essential for DNS resolvers to be able to reach your servers directly.

Installation on the DNS slave server

Installation example for Debian 12.

1. Installing Bind9

In root :

apt update && apt upgrade
apt install bind9 bind9-utils bind9-doc

2. Configuration named (BIND9)

Let's edit the first configuration file:

nano /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    listen-on { any; };
    listen-on-v6 { any; };

    dnssec-validation auto; // default config
    recursion no; // no resolver function
    allow-query { any; }; // allow public DNS queries
    allow-transfer { none; }; // no zone transfers to others
    allow-new-zones yes; // required for rndc addzone
    auth-nxdomain no; // RFC1035 compliance
    version "none"; // hide version info
};

3. Control configuration rndc

The rndc protocol is used to authorize control access to DNS slaves.

Edit the second configuration file :

nano /etc/bind/named.conf.local

Authorize the IPs of your DNS master (Plesk server) here:

controls {
    inet * port 953 allow { IPv4_PLESK; IPv6_Plesk ; 127.0.0.1; };
};

4. Raise the key rndc

The key is stored in /etc/bind/rndc.key.

Display and write down the key, which you'll need for Plesk configuration.

cat /etc/bind/rndc.key
key "rndc-key" {
        algorithm hmac-md5;
        secret "xxxxxxxxxxxxxxxxxxxxxxxxx==";
};

5. Restart BIND (named)

Restart the service to apply the config. Let's also check that everything is working normally.

systemctl restart named
rndc status

Repeat this operation for each DNS slave.

Plesk configuration (master server)

1. Install extension Slave DNS Manager

In the Plesk interface :
Extensions → Catalog → Slave DNS Manager → Install

2. Add your Slavic servers

Open Tools & Settings → Extensions → Slave DNS Manager → Settings

Add each slave server with :

  • IP address Master IPv4 (Plesk server)
  • IP address IPv4 slave server
  • Port (RNDC): 953
  • Algorithm : hmac-sha256
  • Secret key the one recovered in /etc/bind/rndc.key
  • Server name (optional) : ns1.example.net

The extension will automatically create a local configuration for rndc.

3. Refresh and resync

On the Plesk DNS Slave management home page :

  • Click on Refresh
  • Then click on Resynchronize

If everything is green: then the configuration is probably good.

How it works

As soon as a DNS zone is :

  • created,
  • modified,
  • or deleted

on the Plesk server, the Slave DNS Manager automatically sends the following commands to each slave server:

ActionOrder executed
Creation/usr/sbin/rndc -c slave.config addzone example.com '{ type slave; file "/var/lib/bind/example.com"; masters { ; }; };'
Update/usr/sbin/rndc -c slave.config refresh example.com
Delete/usr/sbin/rndc -c slave.config delzone example.com

🧱 Structure of a default DNS zone

When a new domain is created on the server, Plesk automatically generates a DNS zone from a default template.
This model can (and must) be adapted to your hosting infrastructure to ensure consistency, security and smooth running of services.

At LRobThe default DNS zone contains all records essential for web, e-mail and domain security:

RecordingTypeValue / ExampleDescription
.A<ip>Main IPv4 address of the site
.AAAA<ipv6>Main IPv6 address of the site
.MX (10)mail..Domain mail server
.TXTv=spf1 +mx include:_spf.lrob.net -allSPF policy authorizing shipments via LRob
.NS.DNS master server (Plesk)
.CAA (issuewild)letsencrypt.orgAllow Let's Encrypt to issue certificates
.TXTHosted by www.lrob.fr | WordPress Security ExpertWordPress Security Expert`
.NSns1.lrob.net.Secondary DNS server n°1
.NSns2.lrob.net.Secondary DNS server n°2
.NSns3.lrob.net.Secondary DNS server no. 3
_dmarc..TXTv=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarcreport@lrob.fr; ruf=mailto:dmarcreport@lrob.fr; rf=afrf; pct=100; ri=172800Strict DMARC policy for e-mail authentication
ftp..CNAME.Alias for FTP
mail..A / AAAA<ip> / <ipv6>Mail server pointing to main host
webmail..CNAMEmail..Alias for webmail access
www..CNAME.Alias for the main site

Remarks

  • This configuration guarantees SPF + DMARC compliancethe DNS redundancyand compatibility Let's Encrypt thanks to registration CAA.
  • Registration TXT "Hosted by LRob" adds a touch of identification and transparency.
  • The servers NS must point to your declared secondary DNS servers (including glue records).

🔍 Testing and validation

Check external resolution

From any station:

dig @ns1.example.net example.com
dig @ns2.example.net example.com
🤖 LRobot, your AI assistant