Aller au contenu

Fiche recette - Configuration bind9

Bannière CUB


Informations

  • Auteur : Louis MEDO
  • Date : 23/09/2026
  • Domaine : Exploitation services

1. Contexte du test

Cette fiche recette consigne les opérations de diagnostic pour valider la configuration du service DNS Bind9. Les tests sont à exécuter exclusivement sur les serveurs autoritaires 192.36.4.10 (maître) et 192.36.4.11 (secondaire). Le but est de garantir la validité syntaxique des fichiers, la bonne exécution du démon, la résolution correcte des enregistrements, l'absence de récursivité externe, ainsi que l'effectivité des transferts de zone (AXFR).

2. Procédures de validation

Vider le cache DNS

Cette commande est utile pour pour vider le cache DNS sur le service Unbound.

sudo unbound-control flush_zone votre.domaine

Démarrage du serveur et traces

SAUF s'il y a une erreur de syntaxe dans les fichiers de configuration globaux, le serveur va apparemment démarrer ou redémarrer sans erreur. Pour voir si tout c'est réellement bien passé, il faut lire les fichiers de trace (logs).

2.1. Vérification de la syntaxe globale

Objectif : Vérifier les fichiers de configuration globale fournis par le paquet dnsutils pour détecter les éventuelles erreurs de syntaxe (par exemple, les nombreux ";" oubliés) avant le redémarrage.

Commande utilisée :

sudo named-checkconf
  • named-checkconf : Utilitaire vérifiant la validité syntaxique des fichiers de configuration globale de bind.

Résultat attendu :

Ne retourne rien

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................

2.2. Vérification de la syntaxe du fichier de zone

Objectif : S'assurer de la validité de la syntaxe des fichiers de zone pour prévenir le rejet du fichier au démarrage (ex: parenthèses mal placées de l'enregistrement SOA ou noms pleinement qualifiés non suffixés par un point).

Commande utilisée :

named-checkconf -z
  • named-checkzone : Commande permettant de vérifier la syntaxe d'un fichier de zone spécifique.
  • -z : Option pour charger et vérifier la configuration des zones déclarées.

Résultat attendu :

zone ns0.dortmund.cub.sioplc.fr/IN: loaded serial 2026092301
OK
# Il ne faut pas toujours se fier au "OK" final mais lire les phrases qui précèdent...

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................

2.3. Contrôle du démarrage du service dans les journaux

Objectif : Contrôler en direct le bon démarrage ou redémarrage du service Bind9 pour s'assurer que les zones sont bien chargées sans erreur.

Commande utilisée :

tail -f /var/log/bind.log
  • tail : Affiche la fin d'un fichier.
  • -f : Permet de lire en direct les fichiers de trace concernant le démon named au fur et à mesure des événements.
  • /var/log/bind.log : Chemin vers le fichier de trace dédié au démon DNS.

Résultat attendu :

# Exécution sans erreurs. Si un problème survient, le log indiquera "failed: file not found" ou "unexpected end of input".

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................

Gestion du cache lors des tests

Attention au cache qui pourrait fournir des réponses qui ne sont plus valables; la commande rndc flush permet de supprimer toutes données en cache.

2.4. Vérification des données relatives à la zone

Objectif : Interroger le serveur DNS pour valider qu'il répond correctement aux requêtes sur sa zone, en contrôlant les sections ANSWER et AUTHORITY.

Commande utilisée :

dig @192.36.4.10 ns0.dortmund.cub.sioplc.fr A
  • dig : Commande non interactive (Domain Information Groper) permettant de vérifier les données relatives à chaque zone avec beaucoup de détails.
  • @192.36.4.10 : Spécifie le serveur cible à interroger.
  • ns0.dortmund.cub.sioplc.fr : FQDN à résoudre.
  • A : Précise le type de RR (Resource Record) à filtrer dans la requête.

Résultat attendu :

; <<>> DiG 9.5.0-P2 <<>> ns0.dortmund.cub.sioplc.fr
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12560
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns0.dortmund.cub.sioplc.fr.          IN      A
;; ANSWER SECTION:
ns0.dortmund.cub.sioplc.fr.   86233   IN      A       192.168.10.10
# (La section ANSWER donne la réponse à la requête).

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................

2.5. Vérification de la non récursivité

Objectif : Vérifier que le serveur DNS refuse les requêtes récursives émanant de clients externes à l'infrastructure réseau.

Commande utilisée :

dig @192.36.4.10 loutik.fr
  • dig : Outil d'interrogation DNS.
  • @192.36.4.10 : Cible le serveur DNS devant interdire la récursivité.
  • loutik.fr : Nom de domaine externe à la zone gérée pour forcer une requête récursive.

Résultat attendu :

;; ->>HEADER<< opcode: QUERY, status: REFUSED, id: 20371
; EDE: 20 (Not Authoritative): (recursion disabled)
# (La requête doit être refusée si demande récursive à partir d'un poste n'appartenant pas au réseau).

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................

2.6. Contrôle des transferts de zone (AXFR)

Objectif : S'assurer que le serveur secondaire (192.36.4.11) réussit à synchroniser les enregistrements de la zone depuis le serveur maître (192.36.4.10).

Commande utilisée :

grep -i "transfer" /var/log/bind.log
  • grep : Permet de rechercher un motif précis dans un fichier texte.
  • -i : Rend la recherche insensible à la casse.
  • "transfer" : Mot clé recherché pour lire les fichiers de trace concernant le lancement d'un serveur secondaire ou une modification de zone.
  • /var/log/bind.log : Fichier de journalisation de Bind9.

Résultat attendu :

# Sur le serveur maître :
client 192.36.4.11#56170: transfer of 'ns0.dortmund.cub.sioplc.fr': AXFR started
client 192.36.4.11#56170: transfer of 'ns0.dortmund.cub.sioplc.fr': AXFR ended

# Sur le serveur secondaire :
zone ns0.dortmund.cub.sioplc.fr: Transfer started.
transfer of 'ns0.dortmund.cub.sioplc.fr' from 192.36.4.10#53: Transfer completed

Statut :

  • Ok
  • KO

Commentaire :

................................................................................................................................................................................................................................................................................................................................................................