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-doc2. Configuration named (BIND9)
Let's edit the first configuration file:
nano /etc/bind/named.conf.optionsoptions {
    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.localAuthorize 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.keykey "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 statusRepeat 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:
| Action | Order 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:
| Recording | Type | Value / Example | Description | 
|---|---|---|---|
| . | A | <ip> | Main IPv4 address of the site | 
| . | AAAA | <ipv6> | Main IPv6 address of the site | 
| . | MX (10) | mail.. | Domain mail server | 
| . | TXT | v=spf1 +mx include:_spf.lrob.net -all | SPF policy authorizing shipments via LRob | 
| . | NS | . | DNS master server (Plesk) | 
| . | CAA (issuewild) | letsencrypt.org | Allow Let's Encrypt to issue certificates | 
| . | TXT | Hosted by www.lrob.fr | WordPress Security Expert | WordPress Security Expert` | 
| . | NS | ns1.lrob.net. | Secondary DNS server n°1 | 
| . | NS | ns2.lrob.net. | Secondary DNS server n°2 | 
| . | NS | ns3.lrob.net. | Secondary DNS server no. 3 | 
| _dmarc.. | TXT | v=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarcreport@lrob.fr; ruf=mailto:dmarcreport@lrob.fr; rf=afrf; pct=100; ri=172800 | Strict DMARC policy for e-mail authentication | 
| ftp.. | CNAME | . | Alias for FTP | 
| mail.. | A / AAAA | <ip>/<ipv6> | Mail server pointing to main host | 
| webmail.. | CNAME | mail.. | 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 NSmust 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


