Table des matières
BIND9 : zone secondaire, délégation et transferts
Formation : BTS SIO — Option SISR
1. Rôle et architecture
BIND9 peut publier des zones DNS faisant autorité. Dans l'exemple, ns0 (192.36.3.10) est primaire et ns1 (192.36.3.11) est secondaire pour californie.cub.sioplc.fr. Les résolveurs dns0 et dns1 remplissent un autre rôle.
Les changements de zone se font sur le primaire. Le secondaire conserve la copie transférée ; il ne faut pas éditer cette copie comme un fichier de zone de référence.
2. Identification locale
La correspondance entre le nom court et le FQDN dans /etc/hosts facilite la résolution locale. Elle ne définit ni l'adresse de l'interface ni un enregistrement public.
Identification locale du secondaire ns1.
3. Déclarer la zone secondaire
Extrait de /etc/bind/named.conf.local, reprenant la syntaxe observée :
zone "californie.cub.sioplc.fr" {
type slave;
masters { 192.36.3.10; };
file "/var/cache/bind/db.californie.cub.sioplc.fr";
};
secondary et primaries sont les termes actuels correspondant à slave et masters. Vérifier la version installée avant de modifier une configuration existante.
Zone secondaire et adresse du primaire.
Le primaire doit autoriser le transfert vers le secondaire et le réseau doit laisser passer les échanges nécessaires, notamment TCP 53 pour AXFR. La déclaration locale ne prouve pas à elle seule que le transfert fonctionne.
4. Journaliser les événements
Dans /etc/bind/named.conf.log :
logging {
channel bind_log {
file "/var/log/bind.log" versions 3 size 100m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { bind_log; };
};
Inclure ce fichier depuis la configuration générale :
include "/etc/bind/named.conf.log";
Canal de journalisation avec rotation.
Inclusion du fichier de journalisation.
Vérifier les droits d'écriture et le confinement AppArmor. La catégorie default ne signifie pas que toutes les requêtes des clients seront journalisées.
5. Déléguer la zone depuis son parent
Dans la zone parente cub.sioplc.fr, les enregistrements concernés sont :
californie IN NS ns0.californie.cub.sioplc.fr. californie IN NS ns1.californie.cub.sioplc.fr. ns0.californie IN A 192.36.3.10 ns1.californie IN A 192.36.3.11
Les enregistrements A fournissent les données de raccordement pour ces serveurs situés dans la zone déléguée. Augmenter le numéro de série de la zone parente lors de sa modification, contrôler sa syntaxe puis la recharger.
Délégation et glue records dans la zone parente.
Le commentaire « délégation Anvers » visible dans la capture provient d'un modèle ; les enregistrements montrés concernent Californie.
sudo named-checkconf -z # Après contrôle réussi, sur le serveur de la zone parente : sudo rndc reload cub.sioplc.fr
Chargement de la zone parente, série 2026100802.
6. Vérifier le transfert
tail -n 80 /var/log/bind.log dig @192.36.3.10 californie.cub.sioplc.fr SOA +norecurse dig @192.36.3.11 californie.cub.sioplc.fr SOA +norecurse
Dans les journaux conservés, une première tentative échoue avec SERVFAIL. Une tentative ultérieure réussit : le secondaire affiche Transfer status: success et Transfer completed pour la série 2026100801. Le primaire enregistre le même numéro de série et un AXFR de six enregistrements.
Transfert réussi sur ns1 après une première erreur.
AXFR vers ns1 enregistré sur le primaire.
Ces événements valident le transfert à l'instant capturé. Les messages IPv6 network unreachable restent un diagnostic distinct du transfert IPv4 réussi.
7. Contrôler le parcours de résolution
dig +trace ns0.californie.cub.sioplc.fr
Fin de la trace : réponse provenant du secondaire 192.36.3.11.
La trace aboutit à ns0.californie.cub.sioplc.fr A 192.36.3.10. Elle démontre ce parcours et cette réponse, pas le basculement automatique d'un client entre dns0 et dns1.