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-doc2. Configuration named (BIND9)
Éditons le premier fichier de configuration :
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. 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.localAutorisez 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.keykey "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 statusRé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 :
| Action | Commande 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 :
| Enregistrement | Type | Valeur / Exemple | Description |
|---|---|---|---|
<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>. | TXT | v=spf1 +mx include:_spf.lrob.net -all | Politique SPF autorisant les envois via LRob |
<domain>. | NS | <hostname>. | Serveur maître DNS (Plesk) |
<domain>. | CAA (issuewild) | letsencrypt.org | Autorise Let’s Encrypt à émettre des certificats |
<domain>. | TXT | Hosted by www.lrob.fr | WordPress Security Expert | WordPress Security Expert` |
<domain>. | NS | ns1.lrob.net. | Serveur DNS secondaire n°1 |
<domain>. | NS | ns2.lrob.net. | Serveur DNS secondaire n°2 |
<domain>. | NS | ns3.lrob.net. | Serveur DNS secondaire n°3 |
_dmarc.<domain>. | 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 | Politique 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>. | CNAME | mail.<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
NSdoivent 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
