Déployer des serveurs DNS secondaires (slave DNS) pour Plesk

L’objectif est de mettre en place un ou plusieurs serveurs DNS secondaires (slaves) synchronisés automatiquement avec un serveur Plesk principal (master DNS).
Cette architecture améliore la résilience, la rapidité de propagation DNS, la simplicité, et la fiabilité globale de votre infrastructure d’hébergement.

Cette procédure est appliquée lors de la souscription à l’option de management des slave DNS via l’offre d’infogérance LRob. Elle vous donnera tous les pré-requis et vous éclairera sur la procédure et le système en place dans ce contexte.

Pré-requis

Matériel et architecture

  • Un VPS 1 à 2 vCores et 1 à 2 Go de RAM suffisent largement (hors trafic massif : >1M de requêtes/heure).
  • 2 à 3 serveurs slave DNS sont recommandés pour la redondance.
  • Compatible ARM64 ou x86_64.
  • Système recommandé : Debian – stable, léger, largement supporté.
  • Chaque serveur slave doit être :
    • Hébergé sur un réseau / fournisseur distinct (subnet différent).
    • Accessible en IPv4 et IPv6, chacune avec une IP dédiée.
    • Disposant d’un nom d’hôte (hostname) unique et correct.
    • Avec un rDNS (reverse DNS) correspondant à son hostname.

Nommage et domaine

  • Dédiez un domaine d’infrastructure pour vos serveurs DNS, par exemple :
    example.net
  • Déclarez les glue records IPv4 et IPv6 auprès de votre registre de domaine :
    Exemple : ns1.example.net, ns2.example.net, ns3.example.net
  • Définissez ces glue records en tant que serveurs DNS de votre domaine.

Ces enregistrements sont indispensables pour que les résolveurs DNS puissent joindre directement vos serveurs.

Installation sur le serveur slave DNS

Exemple d’installation pour Debian 12.

1. Installation de Bind9

En root :

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

2. Configuration named (BIND9)

Éditons le premier fichier de configuration :

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. Configurer le contrôle rndc

Le protocole rndc permet d’autoriser l’accès de contrôle sur les slave DNS.

Éditez le second fichier de configuration :

nano /etc/bind/named.conf.local

Autorisez ici les IP de votre master DNS (serveur Plesk) :

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

4. Relever la clé rndc

La clé est stockée dans /etc/bind/rndc.key.

Affichez et notez la clé, vous en aurez besoin pour la configuration côté Plesk.

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

5. Redémarrer BIND (named)

Redémarrons le service pour appliquer la config. Vérifions aussi que tout fonctionne normalement.

systemctl restart named
rndc status

Répétez cette opération pour chaque slave DNS.

Configuration côté Plesk (serveur maître)

1. Installer l’extension Slave DNS Manager

Dans l’interface Plesk :
Extensions → Catalogue → Slave DNS Manager → Installer

2. Ajouter vos serveurs slaves

Ouvrez Outils & Paramètres → Extensions → Slave DNS Manager → Paramètres

Ajoutez chaque serveur slave avec :

  • Adresse IP : IPv4 du master (serveur Plesk)
  • Adresse IP : IPv4 du serveur slave
  • Port (RNDC) : 953
  • Algorithme : hmac-sha256
  • Clé secrète : celle récupérée dans /etc/bind/rndc.key
  • Nom du serveur (optionnel) : ns1.example.net

L’extension créera automatiquement une configuration locale pour rndc.

3. Rafraîchir et resync

Sur la page d’accueil de gestion des Slave DNS de Plesk :

  • Cliquez sur Rafraîchir
  • Puis sur Resynchroniser

Si tout est vert : alors la configuration est probablement bonne.

Fonctionnement

Dès qu’une zone DNS est :

  • créée,
  • modifiée,
  • ou supprimée

sur le serveur Plesk, le Slave DNS Manager envoie automatiquement les commandes suivantes à chaque serveur slave :

ActionCommande exécutée
Création/usr/sbin/rndc -c slave.config addzone example.com '{ type slave; file "/var/lib/bind/example.com"; masters { <IP_Plesk>; }; };'
Mise à jour/usr/sbin/rndc -c slave.config refresh example.com
Suppression/usr/sbin/rndc -c slave.config delzone example.com

🧱 Structure d’une zone DNS par défaut

Lorsqu’un nouveau domaine est créé sur le serveur, Plesk génère automatiquement une zone DNS à partir d’un modèle par défaut.
Ce modèle peut (et doit) être adapté à votre infrastructure d’hébergement pour garantir cohérence, sécurité et bon fonctionnement des services.

Chez LRob, la zone DNS par défaut contient tous les enregistrements essentiels pour le web, le courrier électronique et la sécurité du domaine :

EnregistrementTypeValeur / ExempleDescription
<domain>.A<ip>Adresse IPv4 principale du site
<domain>.AAAA<ipv6>Adresse IPv6 principale du site
<domain>.MX (10)mail.<domain>.Serveur de messagerie du domaine
<domain>.TXTv=spf1 +mx include:_spf.lrob.net -allPolitique SPF autorisant les envois via LRob
<domain>.NS<hostname>.Serveur maître DNS (Plesk)
<domain>.CAA (issuewild)letsencrypt.orgAutorise Let’s Encrypt à émettre des certificats
<domain>.TXTHosted by www.lrob.fr | WordPress Security ExpertWordPress Security Expert`
<domain>.NSns1.lrob.net.Serveur DNS secondaire n°1
<domain>.NSns2.lrob.net.Serveur DNS secondaire n°2
<domain>.NSns3.lrob.net.Serveur DNS secondaire n°3
_dmarc.<domain>.TXTv=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarcreport@lrob.fr; ruf=mailto:dmarcreport@lrob.fr; rf=afrf; pct=100; ri=172800Politique DMARC stricte pour l’authentification des e-mails
ftp.<domain>.CNAME<domain>.Alias pour le FTP
mail.<domain>.A / AAAA<ip> / <ipv6>Serveur de messagerie pointant vers l’hôte principal
webmail.<domain>.CNAMEmail.<domain>.Alias pour accéder au webmail
www.<domain>.CNAME<domain>.Alias pour le site principal

Remarques

  • Cette configuration garantit la conformité SPF + DMARC, la redondance DNS, et la compatibilité Let’s Encrypt grâce à l’enregistrement CAA.
  • L’enregistrement TXT “Hosted by LRob” ajoute une touche d’identification et de transparence.
  • Les serveurs NS doivent pointer vers vos serveurs DNS secondaires déclarés (glue records inclus).

🔍 Tests et validation

Vérifier la résolution externe

Depuis n’importe quel poste :

dig @ns1.example.net example.com
dig @ns2.example.net example.com
🤖 LRobot, ton assistant IA