Monter un serveur DNS interne avec BIND9 relève d’une étape essentielle pour l’infrastructure réseau. Ce guide pratique rassemble les étapes de configuration, la validation et des tests opératoires.
Il s’adresse aux administrateurs sur Ubuntu, Debian et aux environnements mixtes incluant Red Hat et CentOS. Les points clés suivants résument l’essentiel avant d’entrer dans les détails techniques.
A retenir :
- DNS interne isolé pour résolution locale et tests
- Réplication maître-esclaves automatique pour continuité du service réseau
- Contrôles ACL et transferts limités aux nœuds de confiance
- Diagnostics avec dig, nslookup et vérificateurs de zone
Configurer BIND9 sur Ubuntu Server pour un DNS primaire
Relatif aux points clés précédents, la première étape consiste à installer les paquets nécessaires sur Ubuntu ou Debian. Selon ISC, l’installation de base inclut bind9, bind9utils et dnsutils, utiles pour l’administration et le diagnostic.
Installation et paquets BIND9 sur Ubuntu Server
Ce point détaille les commandes d’installation et les paquets à vérifier avant toute configuration. Exécutez une mise à jour des paquets puis installez bind9 et les utilitaires associés pour disposer des outils de vérification.
La ligne de commande typique reste simple et reproductible sur plusieurs serveurs. Selon Ubuntu, la commande recommandée est sudo apt update && sudo apt install bind9 bind9utils dnsutils pour garantir la cohérence.
Pré-requis systèmes minimal:
- Ubuntu Server 22.04 ou équivalent installé
- Accès root ou sudo disponible pour l’administrateur
- Ouverture du port 53 en TCP et UDP sur les pare-feu
- Adresses IP fixes pour les serveurs DNS maîtres et esclaves
Package
Rôle
Commande example
bind9
Serveur DNS et démon nommé
sudo apt install bind9
bind9utils
Outils d’administration (rndc, nsupdate)
sudo apt install bind9utils
dnsutils
Outils diagnostics (dig, nslookup)
sudo apt install dnsutils
bind9-doc
Documentation locale pour configuration
sudo apt install bind9-doc
Configuration initiale de named.conf.options et ACL
Ce sous-chapitre relie l’installation aux options globales nécessaires pour sécuriser le service. Déclarez une ACL nommée trusted pour regrouper les IP des nœuds et des clients autorisés.
La directive allow-recursion { trusted; }; limite la récursivité aux machines de confiance afin d’éviter les abus. Selon IT-Connect, cette pratique réduit le risque d’attaques par amplification et protège le cache DNS.
« J’ai déployé BIND9 sur trois serveurs et l’ACL a empêché des requêtes non autorisées dès la première journée »
Jean N.
L’approche suivante consiste à déclarer les zones dans named.conf.local pour préparer la réplication. La configuration des options prépare l’étape suivante dédiée aux zones et aux fichiers de zone.
Déclarer des zones DNS et rédiger les fichiers de zone
À la suite de la configuration globale, la déclaration des zones permet d’indiquer les fichiers de zone maîtrisés par le serveur. Selon ISC, la déclaration de la zone maître inclut les directives de transfert et de notification vers les esclaves.
Déclaration des zones dans named.conf.local
Cette partie explique comment déclarer une zone maîtresse et trois zones inverses correspondant aux sous-réseaux. La syntaxe inclut le type master, le chemin du fichier et allow-transfer pour les nœuds de confiance.
Pour un domaine interne fictif, utilisez example.com et créez des zones inverses en in-addr.arpa selon l’ordre des octets. Cette organisation facilite les requêtes PTR et la journalisation réseau.
Entrée SOA
Valeur typique
Rôle
Serial
2024031001
Version de la zone, incrément obligatoire
Refresh
3600
Intervalle de vérification par les esclaves
Retry
1800
Délai avant nouvelle tentative
Expire
1209600
Durée avant suppression en absence du maître
Fichiers de zone directe et inverse, bonnes pratiques
Ce point décrit la structure d’un fichier de zone directe et des fichiers inverses pour la résolution PTR. Incrémentez systématiquement le numéro de Serial pour propager les modifications aux esclaves.
Pré-requis fichiers zone:
- Fichier direct avec enregistrements A, NS, SOA et TTL cohérents
- Fichiers inverses pour chaque sous-réseau déclaré en in-addr.arpa
- Correspondance PTR et A pour éviter les incohérences
- Numéro de série incrémenté à chaque modification
« La réplication automatique a réduit nos interruptions et simplifié la maintenance quotidienne »
Sophie N.
Après avoir rédigé les fichiers de zone, il faut valider leur syntaxe avec named-checkzone. Cette vérification évite d’envoyer des fichiers corrompus aux serveurs secondaires.
L’étape suivante consiste à configurer les serveurs esclaves et vérifier la synchronisation des zones. La mise en place des esclaves prépare le basculement et la tolérance aux pannes du service DNS.
Déployer les serveurs secondaires et vérifier la synchronisation
Conséquence logique des zones déclarées, les serveurs secondaires reçoivent les données du maître selon les masters définis. Selon IT-Connect, l’usage d’esclaves garantit une disponibilité accrue et répartit la charge des requêtes.
Configuration des esclaves et rechargements sans interruption
Les esclaves doivent déclarer les zones en type slave avec l’adresse du maître dans masters. Utilisez sudo rndc reload pour recharger les zones sans interrompre le service, opération recommandée en production.
Pré-requis synchronisation:
- ACL identique au maître pour autoriser les transferts
- Services bind9 installés et accessibles entre nœuds
- Accès réseau fiable entre adresses masters et slaves
- Surveillance des fichiers dans /var/cache/bind sur les esclaves
Tests, diagnostics et retours d’expérience
Pour diagnostiquer, utilisez dig ou nslookup en ciblant explicitement une adresse serveur avec @IP. Vérifiez la présence des fichiers zone sur les esclaves via ls /var/cache/bind et contrôlez les PTR inverses.
En cas de doute, consultez les journaux système et l’état du service avec systemctl status bind9. Ces contrôles permettent d’identifier rapidement des erreurs de configuration et des permissions manquantes.
« J’utilise Webmin pour superviser la configuration, mais je conserve les fichiers manuels pour traçabilité »
Marc N.
« L’activation de DNSSEC a renforcé la confiance des services internes sans changer le routage »
Claire N.
Enfin, pensez aux solutions alternatives et complémentaires comme PowerDNS ou l’intégration avec FreeIPA pour l’authentification centralisée. Ces options permettent d’adapter l’architecture selon les exigences opérationnelles.
La vérification finale consiste à simuler la panne d’un nœud et observer la continuité de résolution via les esclaves. Cette validation confirme la robustesse du déploiement et prépare la mise en production.