Serveur DNS BIND 9 primaire et secondaire (master/slave) sous Debian

Deux serveurs qui répondent pour la même zone, l'un qui fait foi, l'autre qui recopie : c'est le montage de base d'un DNS faisant autorité. Voici comment le réaliser avec BIND 9 sur la Debian stable actuelle, et comment prouver que le transfert de zone fonctionne.

Par la rédaction de Pixelabs · 12 octobre 2026

Un serveur DNS faisant autorité ne doit jamais être seul : si la machine tombe, toute la zone disparaît. La documentation de BIND 9 le rappelle, un résolveur utilise la liste des serveurs faisant autorité d'une zone, et il en faut au moins deux. Le montage classique associe un serveur primaire, qui charge la zone depuis un fichier, et un serveur secondaire, qui la récupère par transfert de zone.

Les anciens termes « master » et « slave » désignent la même chose. La documentation de l'ISC précise que, pour des raisons de compatibilité, BIND 9 traite « primary » et « master » comme synonymes, de même que « secondary » et « slave ». Les exemples ci-dessous utilisent les mots actuels, type primary et type secondary.

Testez d'abord sur des machines de lab, et prenez un instantané (snapshot) ou une sauvegarde de /etc/bind avant de modifier un DNS de production.

Quelle version de Debian et de BIND

La version stable actuelle de Debian est Debian 13 « trixie », publiée le 9 août 2025 ; son support régulier court jusqu'au 9 août 2028, puis le LTS jusqu'au 30 juin 2030, selon la page des versions de Debian. Les anciens tutoriels écrits pour Debian 9 « stretch » visent une version sortie du support de sécurité en juillet 2020, et du LTS fin juin 2022.

Debian 13 fournit BIND dans la branche 9.20 (paquet bind9). Deux changements comptent par rapport aux vieux guides :

• le service systemd s'appelle named, et bind9 n'est plus qu'un alias ;
• les mots-clés primary, secondary et primaries remplacent master, slave et masters, qui restent acceptés.

La topologie du lab

Le domaine lab.local sert d'exemple ; remplacez-le par votre zone. Les deux serveurs sont sur le même réseau privé.

Vérifiez le nom d'interface avec ip a ; les deux serveurs doivent avoir une adresse fixe.

Installer BIND 9 sur les deux serveurs

Sur ns1 comme sur ns2, installez le serveur et les outils de diagnostic. Le paquet bind9 dépend de bind9-utils, qui apporte named-checkconf et named-checkzone ; dig est dans bind9-dnsutils.

apt update
apt install bind9 bind9-dnsutils
systemctl status named

Sur Debian, le fichier principal /etc/bind/named.conf inclut named.conf.options, named.conf.local et named.conf.root-hints. Le commentaire du fichier est explicite : les zones s'ajoutent dans /etc/bind/named.conf.local. Le répertoire de travail défini dans named.conf.options est /var/cache/bind.

Configurer le serveur primaire

Déclarer la zone

Sur ns1, déclarez la zone dans named.conf.local. La liste allow-transfer est indispensable : selon la référence de BIND 9.20, sans cette directive, la valeur par défaut est none et les transferts de zone sont désactivés.

zone "lab.local" {
    type primary;
    file "/etc/bind/db.lab.local";
    notify yes;
    allow-transfer { 192.168.10.12; };
};

Le fichier de zone est placé dans /etc/bind avec un chemin complet, comme le recommande le README.Debian du paquet pour les zones dont le serveur est primaire.

Écrire le fichier de zone

Le fichier contient l'enregistrement SOA, les deux serveurs de noms et les adresses. Le numéro de série (ici au format date + compteur) doit augmenter à chaque modification, sinon le secondaire ne recopie rien.

$TTL 3600
@       IN  SOA ns1.lab.local. admin.lab.local. (
                2026101201 ; serial
                3600       ; refresh
                900        ; retry
                604800     ; expire
                3600 )     ; negative cache TTL
        IN  NS  ns1.lab.local.
        IN  NS  ns2.lab.local.
ns1     IN  A   192.168.10.11
ns2     IN  A   192.168.10.12
srv-web01 IN A  192.168.10.20

Les valeurs de temps sont des choix de lab, pas des recommandations. La documentation ISC indique seulement que l'intervalle refresh, la fréquence à laquelle le secondaire interroge le SOA, se règle d'ordinaire en heures pour limiter le trafic.

Vérifier puis recharger

Contrôlez la syntaxe avant tout rechargement.

named-checkconf /etc/bind/named.conf
named-checkzone lab.local /etc/bind/db.lab.local
rndc reload

named-checkzone prend le nom de la zone puis le fichier ; corrigez toute erreur qu'il signale avant de recharger.

Configurer le serveur secondaire

Sur ns2, la zone est déclarée en secondary avec l'adresse du primaire dans primaries. Aucun fichier de zone n'est à écrire : il sera obtenu par transfert.

zone "lab.local" {
    type secondary;
    file "db.lab.local";
    primaries { 192.168.10.11; };
};

Le nom de fichier relatif place la copie dans /var/cache/bind, comme le conseille le README.Debian pour les zones secondaires. Selon la documentation ISC, cette copie permet de répondre dès le redémarrage, sans attendre un transfert.

named-checkconf /etc/bind/named.conf
rndc reload

Comment le transfert de zone fonctionne

La documentation de BIND 9 décrit le cycle ainsi :

1. le secondaire lit périodiquement le SOA du primaire, à l'intervalle refresh ;
2. si le numéro de série reçu est plus grand que le sien, il lance un transfert complet (AXFR) ou incrémental (IXFR), en TCP sur le port 53 ;
3. avec NOTIFY, activé par défaut, le primaire prévient ses secondaires dès qu'il recharge la zone ; le secondaire relit alors le SOA immédiatement.

D'où la conséquence pratique : si un pare-feu entre les deux serveurs ne laisse passer que l'UDP, les requêtes fonctionnent mais le transfert échoue. Pour d'autres serveurs à prévenir que ceux listés en NS, la directive also-notify existe.

Vérifier que tout fonctionne

Depuis le client, interrogez chaque serveur directement. Les deux doivent renvoyer la même adresse et le même numéro de série :

dig @192.168.10.11 srv-web01.lab.local
dig @192.168.10.12 srv-web01.lab.local
dig @192.168.10.12 lab.local SOA

Sur ns2, rndc zonestatus lab.local affiche l'état de la zone. Pour forcer une nouvelle copie, rndc retransfer lab.local relance le transfert depuis le primaire.

Testez aussi la restriction. Depuis le client, une demande de transfert complet doit être refusée par le primaire, puisque seul 192.168.10.12 figure dans allow-transfer :

dig @192.168.10.11 lab.local AXFR

Enfin, modifiez un enregistrement sur ns1, augmentez le numéro de série et rechargez : ns2 doit suivre sans action de votre part.

Les erreurs les plus fréquentes

• Le secondaire garde l'ancienne valeur : le numéro de série n'a pas été augmenté sur le primaire.
• Transfert refusé : l'adresse du secondaire manque dans allow-transfer, ou elle ne correspond pas à l'adresse source réelle (serveur à plusieurs cartes, agrégation de liens).
• Transfert qui expire : TCP 53 filtré entre les deux machines.
• Le service ne démarre plus : une accolade ou un point-virgule manquant ; named-checkconf donne la ligne.

Si vos serveurs DNS tournent sur Rocky Linux plutôt que Debian, la base système est décrite dans le guide d'installation de Rocky Linux. Pour un serveur à deux cartes réseau, la page sur l'agrégation de liens sous Linux explique comment fixer l'interface et l'adresse utilisées. Les commandes ip, systemctl ou journalctl employées ici sont détaillées dans notre liste des commandes Linux.

Côté Windows, le même besoin se traite avec des zones intégrées à Active Directory : voyez la configuration DNS sous Windows Server. Les autres services réseau sont regroupés dans la rubrique Serveurs Linux.

Questions fréquentes