Haute disponibilité DNS avec BIND9 : déploiement pas à pas sur Linux

I. Présentation

Dans cet article, nous allons voir comment déployer une infrastructure DNS en haute disponibilité avec BIND9. L'objectif est de garantir la résolution des noms de domaine même en cas de panne d'un ou plusieurs serveurs.

Nous utiliserons trois serveurs Ubuntu 24.04, chacun positionné sur un réseau différent avec routage inter-sites (niveau 3). Mais, vous pouvez aussi utiliser trois serveurs DNS sur le même site.

Cette configuration permet :

• Une résolution DNS répartie et tolérante aux pannes
• Une synchronisation automatique des zones DNS entre un serveur maître et des serveurs secondaires

Prérequis :

• Trois serveurs Ubuntu 24.04 ou Debian
• Droits sudo/root sur les serveurs
• Connexions réseau entre les nœuds (niveau 3)

A. Principe de fonctionnement

Avant de commencer, sachez que cette architecture repose sur l’utilisation d’un serveur maître (ou primary) et de serveurs esclaves (ou secondary). Cela signifie que :

• Le serveur maître détient les fichiers de zone originaux. Toutes les modifications DNS (ajout, suppression, mise à jour d'enregistrements) sont réalisées uniquement sur ce serveur.
• Les serveurs esclaves, quant à eux, ne possèdent pas ces fichiers directement. Ils se synchronisent automatiquement avec le serveur maître pour en récupérer une copie à jour.

Ce fonctionnement présente plusieurs avantages :

• Il permet de répartir les requêtes DNS entre plusieurs serveurs, améliorant ainsi la disponibilité du service.
• Il garantit une continuité de service, même si le serveur maître devient momentanément indisponible.
• Il centralise les modifications DNS, ce qui simplifie la gestion et limite les erreurs.

Nous allons commencer par effectuer la configuration du serveur maître, puis, dans un second temps, nous verrons comment configurer les serveurs secondaires.

Nous allons également définir les fichiers de zone DNS pour un domaine fictif « example.com », ainsi que trois zones de recherche inversée. Ces zones inverses sont nécessaires, car nos serveurs DNS sont répartis sur trois réseaux différents.

B. Schéma logique

Commençons par une présentation de l'environnement.

II. Installation de BIND9

Sur chacun des trois serveurs, exécutez cet enchainement de commandes pour mettre à jour le cache des paquets et installer le serveur bind9 :

sudo apt update && sudo apt install bind9 bind9-utils

A. Présentation des fichiers BIND par défaut

Lorsque BIND9 est installé, plusieurs fichiers sont créés automatiquement dans le répertoire /etc/bind/. Voici une présentation des fichiers les plus courants et leur utilité :

named.conf	Fichier principal de configuration. Il inclut les autres fichiers de configuration (via des directives include). Il ne contient généralement pas de directives directement.
named.conf.options	C’est ici que l’on configure les options globales du serveur DNS (ex. : récursivité, DNSSEC, ACL). C’est l’un des fichiers que nous modifions dans cette documentation.
named.conf.local	Fichier destiné à accueillir les zones DNS personnalisées, que l’on souhaite ajouter (zones maîtres ou esclaves). Il est vide par défaut.
named.conf.default-zones	Contient les zones de base fournies par défaut avec BIND (comme localhost, 127.0.0.1, etc.). Il est préférable de ne pas modifier ce fichier directement.
bind.keys	Contient les clés publiques utilisées pour valider les signatures DNSSEC des serveurs racine.
rndc.key	Fichier de clé partagée utilisée pour sécuriser les communications entre BIND et l'outil d'administration rndc (Remote Name Daemon Control).
db.127, db.0, db.255	Fichiers de zone inverse pour les plages d’adresses IPv4 spéciales (127.0.0.1 pour localhost, réseau 0.0.0.0, etc.).
db.local	Zone directe associée au nom localhost.
db.empty	Zone vide, utilisée pour désactiver certaines zones ou tests.
zones.rfc1918	Fichier optionnel contenant des zones inverses pour les plages d’adresses privées définies dans la RFC 1918 (10.0.0.0/8, 192.168.0.0/16, etc.). Il peut être inclus manuellement dans named.conf.default-zones si besoin.

III. Configuration de BIND

Les fichiers de configuration principaux de BIND se trouvent dans le répertoire /etc/bind/. Plus précisément, les modifications abordées ici concernent le fichier /etc/bind/named.conf.options pour les options globales et les ACL, ainsi que /etc/bind/named.conf.local pour la déclaration des zones DNS.

A. ACL et options globales dans BIND9

Pour renforcer la sécurité de votre serveur DNS et limiter les actions possibles selon l'origine des requêtes, nous allons définir une liste de contrôle d'accès (ACL) et configurer les options globales du serveur DNS.

Il est impératif d'intégrer la déclaration de l'ACL avant le bloc options, car une ACL doit être définie en amont pour être utilisable dans ce bloc.

B. Déclaration de l’ACL “trusted”

Avant de configurer le bloc options, il est essentiel de déclarer une ACL. Une ACL dans BIND permet de regrouper des adresses IP sous un même nom logique. Ici, nous définissons une ACL nommée trusted qui regroupe les adresses IP de nos trois serveurs DNS.

acl "trusted" {
  10.10.10.10; // Serveur DNS 1
  192.168.1.10; // Serveur DNS 2
  192.168.30.10; // Serveur DNS 3
  10.10.10.0/24; // Réseau clients
};

Cette ACL sera ensuite utilisée pour restreindre certaines fonctionnalités comme la récursivité et le transfert de zones uniquement à ces adresses de confiance.

Il peut sembler inutile d'inclure l'adresse IP du serveur DNS lui-même (par exemple, 10.10.10.10 sur le DNS 1) dans cette liste, mais cela est recommandé.

Même si un serveur DNS ne transfère pas de zones à lui-même, il peut être amené à effectuer des requêtes en local, exécuter des scripts ou se reconfigurer dynamiquement. BIND applique les mêmes règles de filtrage à toutes les requêtes, même celles provenant du serveur lui-même.

Inclure sa propre IP dans l'ACL permet donc :

• D’éviter des blocages lors d’accès locaux ou internes,
• De conserver une configuration cohérente sur tous les serveurs,
• D’anticiper un éventuel changement de rôle (par exemple, si un esclave devient maître).

Ainsi, même si cela ne déclenche pas de transfert réel, cette pratique renforce la robustesse et la simplicité de la configuration.

C. Bloc “options” : configuration globale de BIND

Juste après l’ACL, le bloc options permet de définir le comportement général du serveur DNS.

Voici les principales directives utilisées :

options {
directory "/var/cache/bind";

• directory : définit l’emplacement où seront stockés les fichiers de zone en cache.

dnssec-validation auto;

• dnssec-validation auto : active la validation DNSSEC automatiquement pour renforcer la sécurité des réponses DNS.

DNSSEC (Domain Name System Security Extensions) est une extension de sécurité du DNS. Elle ne chiffre pas les données, mais elle permet de vérifier l’authenticité des réponses DNS. En d'autres termes, elle aide à s'assurer que la réponse reçue vient bien du serveur d'origine et qu'elle n’a pas été modifiée en cours de route.

Concrètement, DNSSEC ajoute une signature numérique aux enregistrements DNS. Lorsqu’un client interroge un serveur DNS, celui-ci peut vérifier cette signature pour valider l'intégrité de la réponse.

Sans DNSSEC, un attaquant pourrait intercepter une requête DNS et y répondre avec de fausses informations, redirigeant l’utilisateur vers un site malveillant. Ce type d’attaque s’appelle une attaque par empoisonnement du cache DNS (DNS cache poisoning).

Avec cette option, BIND va automatiquement effectuer cette vérification de signature lorsqu’un domaine prend en charge DNSSEC. Cela renforce la confiance dans les réponses DNS et améliore la sécurité globale du réseau.

allow-query { any; };

• allow-query { any; }; : autorise toutes les adresses IP à interroger ce serveur DNS. Cela peut être restreint selon les besoins.

allow-recursion { trusted; };

• allow-recursion { trusted; }; : Cette directive permet d'autoriser uniquement certaines machines précises (celles listées dans l’ACL trusted) à utiliser la fonction de récursivité du serveur DNS.

La récursivité, c’est lorsque le serveur DNS va lui-même chercher une réponse complète à une question qu’il ne connaît pas encore. Par exemple, si un poste lui demande l’adresse IP de www.example.com, il va interroger plusieurs autres serveurs DNS sur Internet, un par un, jusqu’à trouver l’information. Il commence par un serveur racine, puis continue vers les serveurs du domaine (par exemple.com), et enfin vers le serveur qui connaît vraiment example.com.

Ce mécanisme est utile, mais aussi risqué s’il est accessible à n’importe qui. Un pirate pourrait envoyer beaucoup de fausses demandes pour forcer votre serveur à faire ce travail à sa place, ce qui peut l’épuiser ou servir à attaquer d'autres systèmes.

En limitant cette fonction aux machines de confiance, on évite qu’un usage abusif ou malveillant ne compromette la stabilité ou la sécurité du serveur. C’est une bonne pratique pour tout serveur DNS exposé.

allow-transfer { trusted; };

• allow-transfer { trusted; }; : seuls les serveurs de confiance peuvent effectuer un transfert de zone, une mesure importante pour éviter la fuite d'informations DNS.

recursion yes;

• recursion yes; : active la récursivité côté serveur, indispensable pour une résolution complète des noms.

listen-on-v6 { none; };};

• listen-on-v6 { none; }; : désactive l’écoute IPv6 si elle n’est pas utilisée.

À ce stade, voici à quoi devrait ressembler votre fichier /etc/bind/named.conf.options

acl "trusted" {
    10.10.10.10;  // Serveur DNS 1
    192.168.1.10;  // Serveur DNS 2
    192.168.30.10; // Serveur DNS 3
    10.10.10.0/24; // Réseau clients
};

options {
    directory "/var/cache/bind";

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable
    // nameservers, you probably want to use them as forwarders.
    // Uncomment the following block, and insert the addresses replacing
    // the all-0's placeholder.

    // forwarders {
    //      0.0.0.0;
    // };

    //========================================================================
    // If BIND logs error messages about the root key being expired,
    // you will need to update your keys.  See https://www.isc.org/bind-keys
    //========================================================================
    dnssec-validation auto;

    // Définition des permissions basées sur l'ACL
    allow-query { any; };
    allow-recursion { trusted; };
    allow-transfer { trusted; };
    recursion yes;

    listen-on-v6 { none; };
};

IV. Configuration des zones DNS

Une fois les options globales en place, il faut déclarer les zones DNS que notre serveur va gérer. Ces déclarations se font dans le fichier /etc/bind/named.conf.local, qui est prévu pour accueillir les zones personnalisées.

zone "example.com" IN {
    type master;                       // Ce serveur est le maître de cette zone.
    file "/etc/bind/db.example.com";   // Fichier contenant les enregistrements DNS de la zone.
    allow-transfer { trusted; };       // Autorise les serveurs de confiance à répliquer cette zone.
    also-notify { 192.168.1.10; 192.168.30.10; }; // Notifie automatiquement les serveurs secondaires quand la zone est modifiée.
};

Voici les déclarations pour trois sous-réseaux utilisés dans notre infrastructure :

zone "10.10.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.10.10.10";
    allow-transfer { trusted; };
};

zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.192.168.1";
    allow-transfer { trusted; };
};

zone "30.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.192.168.30";
    allow-transfer { trusted; };
};

Le nom des zones inverses suit un ordre inversé des octets de l’adresse réseau, suivi de in-addr.arpa. Par exemple, pour le sous-réseau 192.168.1.0/24, la zone est 1.168.192.in-addr.arpa.

À ce stade, voici à quoi devrait ressembler votre fichier /etc/bind/named.conf.local.

zone "example.com" IN {
    type master;
    file "/etc/bind/db.example.com";
    allow-transfer { trusted; };
    also-notify { 192.168.1.10; 192.168.30.10; };
};

zone "10.10.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.10.10.10";
    allow-transfer { trusted; };
};

zone "1.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.192.168.1";
    allow-transfer { trusted; };
};

zone "30.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.192.168.30";
    allow-transfer { trusted; };
};

Pourquoi écrit-on 1.168.192.in-addr.arpa pour une zone inverse ?

En DNS, lorsqu'on veut retrouver un nom de domaine à partir d'une adresse IP, on utilise une zone inverse (reverse DNS). Cette zone permet de faire l'opération inverse de la résolution classique : retrouver un nom à partir d'une IP.

Le format utilisé suit une règle spécifique imposée par le protocole DNS :

• On prend l'adresse IP du sous-réseau concerné (par exemple : 192.168.1.30)
• On inverse l’ordre des octets de l’adresse (car le DNS fonctionne de droite à gauche dans ses recherches)
• On ajoute le suffixe .in-addr.arpa, qui est réservé aux zones inverses pour IPv4

Exemple :

Pour une machine ayant l’adresse IP 192.168.1.30, la zone inverse est basée sur le sous-réseau 192.168.1.30/24.
On inverse les octets : 1.168.192, puis on ajoute .in-addr.arpa.192.168.1.30/24.

On obtient donc la zone suivante :
1.168.192.in-addr.arpa

C’est cette zone que l’on déclare dans le fichier named.conf.local, afin que le serveur DNS sache répondre à des requêtes de type PTR (ex. : "quel est le nom associé à 192.168.1.30 ?").

V. Fichiers de zone

Les fichiers de zone contiennent les enregistrements DNS (A, PTR, NS, etc.) correspondant aux zones définies dans le fichier named.conf.local.

A. Fichier de zone directe : /etc/bind/db.example.com

$TTL    86400 
@       IN      SOA     ns1.example.com. admin.example.com. (
                                2024031001 ; Serial
                                3600       ; Refresh
                                1800       ; Retry
                                1209600    ; Expire
                                86400 )    ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.
ns1     IN      A       10.10.10.10
ns2     IN      A       192.168.1.10
ns3     IN      A       192.168.30.10
client  IN      A       10.10.10.100

$TTL : durée de vie par défaut des enregistrements DNS (ici : 24h)
Concrètement, cela signifie : « Quand un autre serveur DNS me demande cette information, il a le droit de la garder en cache pendant ce délai. »

@ représente le domaine actuel (ex: example.com).

IN signifie (Internet) (c’est la classe de l’enregistrement DNS).

SOA (Start of Authority) définit le serveur DNS autoritaire pour cette zone.

ns1.example.com. → C'est le serveur DNS principal de cette zone.

admin.example.com. → Adresse e-mail de l’administrateur DNS (En notation DNS, le premier . remplace le @ des adresses e-mails).

Les paramètres du SOA

2024031001 ; Serial
3600       ; Refresh
1800       ; Retry
1209600    ; Expire
86400 )    ; Minimum TTL

Paramètre	Valeur	Signification
Numéro de série	2024031001	Version actuelle de la zone il doit être incrémentée (ex: 2024031002, 2024031003, etc.) à chaque modification
Refresh	3600 (1 heure)	Temps avant qu'un serveur secondaire ne vérifie les mises à jour auprès du maître.
Retry	1800 (30 minutes)	Temps d’attente avant une nouvelle tentative si le serveur maître ne répond pas.
Expire	1209600 (14 jours)	Si le serveur secondaire ne peut pas contacter le maître après 14 jours, il supprime la zone.
Minimum TTL	86400 (24 heures)	Indique combien de temps un résolveur DNS doit conserver un enregistrement négatif en cache.

Pourquoi faut-il incrémenter le numéro de série à chaque modification ?

• Les serveurs secondaires synchronisent leurs zones avec le serveur maître à intervalles réguliers (défini par Refresh).
• Ils vérifient le numéro de série du SOA pour voir si la zone a changé.
• Si le numéro de série est plus grand que la dernière version connue, ils demandent une mise à jour.

Si vous oubliez d’incrémenter le numéro de série :

• Les serveurs secondaires ne verront pas les modifications !
• Ils continueront d'utiliser l'ancienne version de la zone.

B. Fichier de zone inverse : /etc/bind/db.10.10.10

$TTL    86400 
@       IN      SOA     ns1.example.com. admin.example.com. (
                                2024031001 ; Serial
                                3600       ; Refresh
                                1800       ; Retry
                                1209600    ; Expire
                                86400 )    ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

10   IN      PTR       ns1.example.com.
100  IN      PTR       client.example.com

C. Fichier de zone inverse : /etc/bind/db.192.168.1

$TTL    86400 
@       IN      SOA     ns1.example.com. admin.example.com. (
                                2024031001 ; Serial
                                3600       ; Refresh
                                1800       ; Retry
                                1209600    ; Expire
                                86400 )    ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

10   IN      PTR       ns2.example.com.

D. Fichier de zone inverse : /etc/bind/db.192.168.30

$TTL    86400 
@       IN      SOA     ns1.example.com. admin.example.com. (
                                2024031001 ; Serial
                                3600       ; Refresh
                                1800       ; Retry
                                1209600    ; Expire
                                86400 )    ; Minimum TTL

@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

10   IN      PTR       ns3.example.com.

Dans un fichier de zone inverse, on écrit le dernier octet de l’adresse IP en premier, car l’adresse complète est sous-entendue dans la configuration.

Qu’est-ce qu’un enregistrement PTR ?

Un enregistrement PTR (Pointer Record) est un type d’enregistrement DNS utilisé dans les zones inverses. Il permet de faire l’opération inverse d’un enregistrement A : au lieu d’associer un nom de domaine à une adresse IP, il associe une adresse IP à un nom de domaine.

Autrement dit, un enregistrement PTR répond à la question suivante : « À qui appartient cette adresse IP ? »

VI. La différence entre une zone directe et une zone inversée

Profitons de ce tutoriel pour faire quelques rappels sur les zones directes et inversées. Il est essentiel de bien assimiler la différence.

Zone directe :

• Permet de traduire un “nom de domaine” en “adresse IP”.
• Exemple : Quand vous tapez “google.com”, le serveur DNS va chercher l’adresse IP associée, comme “142.250.185.206”.

Zone inverse :

• Permet de traduire une “adresse IP” en “nom de domaine”.
• Exemple : Si vous faites une requête inverse sur “142.250.185.206”, le serveur DNS peut vous répondre “google.com”.

Pourquoi utiliser les zones inverses ?

• Utile pour la résolution inverse dans les logs ou les connexions sécurisées.
• Vérification des adresses IP dans certains protocoles (ex: mail).

En clair :

• Zone directe → Nom vers IP (google.com → 142.250.185.206)
• Zone inverse → IP vers Nom (142.250.185.206 → google.com)

VII. Synchronisation des serveurs secondaires

Une fois le serveur maître configuré avec ses zones, il est temps de mettre en place les serveurs secondaires. Ceux-ci ne contiennent pas les fichiers de zone en local : ils se synchronisent automatiquement avec le serveur maître.

Cette synchronisation permet de répliquer les zones DNS afin de garantir une continuité de service, même si le serveur principal devient indisponible.

A. Préparation des serveurs secondaires

Les serveurs secondaires doivent avoir :

• Le service bind9 installé,
  
• L’ACL trusted identique à celle du maître dans le fichier /etc/bind/named.conf.options,
  
• Une configuration minimale dans /etc/bind/named.conf.local pour indiquer qu’ils sont esclaves.
  

B. Déclaration des zones en mode slave

Sur chaque serveur secondaire, modifiez le fichier /etc/bind/named.conf.local comme suit :

zone "example.com" IN {
    type slave;
    file "/var/cache/bind/db.example.com";
    masters { 10.10.10.10; };
};

zone "10.10.10.in-addr.arpa" IN {
    type slave;
    file "/var/cache/bind/db.10.10.10";
    masters { 10.10.10.10; };
};

zone "1.168.192.in-addr.arpa" IN {
    type slave;
    file "/var/cache/bind/db.192.168.1";
    masters { 10.10.10.10; };
};

zone "30.168.192.in-addr.arpa" IN {
    type slave;
    file "/var/cache/bind/db.192.168.30";
    masters { 10.10.10.10; };
};

C. Vérifier la syntaxe de la configuration

Avant de redémarrer le service BIND, il est recommandé de valider la syntaxe de la configuration pour éviter les erreurs bloquantes.

Cette vérification s’effectue uniquement sur le serveur maître (type master), car les fichiers de zone ne sont pas présents sur les serveurs secondaires (type slave). Dans notre configuration, il n’est pas nécessaire de redémarrer le service bind9 après une modification de zone. En revanche, il est impératif de recharger la zone pour que les changements (notamment le nouveau numéro de série dans le champ SOA) soient pris en compte et transmis aux serveurs secondaires.

Effectuez cette vérification pour chaque fichier de zone, y compris les zones inverses.

Vérifier le fichier de configuration principal :

sudo named-checkconf

Si la commande ne retourne aucun message, cela signifie que la syntaxe globale est correcte.

Pour contrôler que la syntaxe d'un fichier de zone directe est correcte, utilisez la commande suivante :

sudo named-checkzone example.com /etc/bind/db.example.com

Dans le même esprit, mais pour un fichier de zone inversée :

sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1

D. Redémarrage du service

Après avoir ajouté la configuration, redémarrez BIND pour appliquer les changements :

sudo systemctl restart bind9

E. Recharger la configuration de BIND en production

Lorsqu’on modifie la configuration ou les fichiers de zone, il est préférable d’éviter un redémarrage complet du service DNS, surtout en production. Pour cela, on utilise la commande rndc.

Recharger la configuration sans interruption :

sudo rndc reload

Cette commande permet de recharger les fichiers de configuration et les zones à chaud, sans couper le service DNS.

Recharger une seule zone :

sudo rndc reload example.com

Vérifier le statut du serveur :

sudo rndc status

VIII. Vérification de la synchronisation

Une fois les serveurs DNS configurés (maître et secondaires), il est essentiel de s'assurer que la configuration fonctionne correctement et que les zones sont bien synchronisées.

A. Résolution d’un nom interne depuis les serveurs DNS :

Depuis un serveur DNS, utilisez la commande suivante pour tester la résolution du nom de la machine client.example.com :

sudo dig @10.10.10.10 client.example.com

Le @10.10.10.10 signifie que vous interrogez explicitement le serveur DNS situé à l’adresse 10.10.10.10, et non celui configuré par défaut dans la machine (via /etc/resolv.conf par exemple)..

Si la configuration est correcte, vous devez obtenir une réponse dans la section ANSWER avec l’adresse IP associée à client.example.com.

B. Résolution de noms externes depuis la machine cliente

Sur la machine Ubuntu (client.example.com), je vais configurer les trois serveurs DNS dans les paramètres réseau. Ainsi, si l’un d’eux ne répond plus, la machine pourra tenter de résoudre les noms via les deux autres.

Utilisez une commande dig ou ping sur un nom de domaine public :

dig google.com

sudo ping google.com

Si la machine cliente est bien configurée avec les serveurs DNS internes, et que ceux-ci sont capables de faire du forwarding vers l’extérieur, la résolution doit fonctionner.

C. Vérifier la présence des fichiers de zone sur les serveurs secondaires

Sur chaque serveur secondaire, listez le contenu du dossier /var/cache/bind/ :

ls /var/cache/bind/

Vous devez y trouver les fichiers suivants :

• db.example.com
• db.10.10.10
• db.192.168.1
• db.192.168.30

Ces fichiers sont les “copies automatiques” des zones provenant du serveur maître.

D. Tester la résolution inverse

Vous pouvez également vérifier que la résolution inverse fonctionne correctement :

dig -x 192.168.30.10

Si la zone inverse est bien configurée, vous obtiendrez une réponse de type PTR associant l’adresse IP au nom ns3.example.com.

E. Journaux système

En cas d'erreur ou d'absence de réponse, consultez les journaux BIND pour diagnostiquer les éventuels problèmes :

systemctl status bind9

IX. Conclusion

Grâce à cette architecture répartie sur plusieurs réseaux, vous disposez désormais d’un système DNS hautement disponible, redondant et fiable, adapté à un environnement de production. En configurant correctement les serveurs maîtres et secondaires, vous assurez la continuité de service même en cas de défaillance d’un des nœuds.

Pour aller plus loin et approfondir certains paramètres, vous pouvez consulter la documentation officielle de BIND ainsi que celle déjà réalisée auparavant sur IT-Connect :

• Documentation de Bind9
• Installer un serveur DNS Bind9 sous Linux