Version 1.2.8 - Mis à jour le le 2023-02-03

Philippe Sevre

• installer un serveur DNS bind9 sur une machine Debian Bullseye
• mettre en évidence le fonctionnement du serveur DNS maitre au moyen d'outils de test (host, nslookup ou dig) dans les situations suivantes :
  • nom courts/FQDN
  • résolution directe/inverse
  • depuis un client local/distant
  • test des différents types d'enregistrements (A, CNAME, PTR, SOA, …)
  • résolution hors zone d'autorité (redirection DNS)
• installer un serveur esclave
• mettre en évidence le transfert de zone du maître vers l'esclave
• autres pistes
  • délégation de zones
  • utilisation d'ACL
  • scripting pour automatiser la gestion des fichiers de zone

• domaine, sous-domaine
• zone d'autorité, zone directe/inverse
• enregistrements SOA, NS, A, CNAME, MX, PTR
• le TTL
• résolution directe/inverse
• requête itérative/récursive
• serveur maître/esclave/cache
• transfert de zone
• délégation de zone
• les roots serveurs
• les clients (résolveurs)
• les outils de test
• tolérance de panne
• sécurité

• une machine Linux Debian Bullseye opérationnelle avec la couche réseau fonctionnelle
• le domaine concerné s'appelle domaine.lan
• le réseau est en 192.168.1.0
• le serveur s'appelle srv1 (192.168.1.1)
• on dispose d'une machine poste1 (192.168.1.100)

On installera les paquetages suivants : bind9, bind9-doc, dnsutils (pour les clients)

Les fichier de configuration sont situés dans /etc/bind

Il contient des includes vers les autres fichiers de configuration.

Il doit comprendre les déclarations de zone : ici la zone maitre directe domaine.lan et la zone inverse arpa 1.168.192-in-addr.arpa.

	// zone directe
        zone "domaine.lan" {
             type master;
             file "/etc/bind/db.domaine.lan";
        };

	// zone inverse 
	zone "1.168.192.in-addr.arpa" {
	     type master;
             notify no;
             file "/etc/bind/db.domaine.lan.rev";
	};

On pourra se servir du fichier db.local comme base de travail en le copiant. Il devra comporter au minimum un enregistrement SOA, un NS et un A correspondant au NS.

On créera également d'autres enregistrements A et des Alias (CNAME). :

• poste1 192.168.1.50
• poste2 192.168.1.51
• www cname poste1 (www est un alias de poste1)

On pourra se servir du fichier db.local comme base. Il devra comporter au minimum

• un enregistrement SOA (Start Of Authority),
• un NS (Name Server)
• et un PTR correspondant au NS.

On créera également d'autres enregistrements PTR.

Remarque générale à propos des test

Il est très intéressant d'ouvrir une console (avec Alt-Fx) qui servira à observer les logs de bind9 au moyen de la commande suivante :

tail -f /var/log/syslog

Il peut être intéressant en cas de problème de syntaxe sur les fichiers de zone, de tester ceux-ci avec la commande zonecheck

Il faudra également prendre garde aux point terminaux obligatoires dans les FQDN.

doit contient les élements suivants :

search domaine.lan
nameserver 127.0.0.1

• préparer la console d'observation des logs (voir plus haut)
• relancer le démon bind9
• vérifier le fonctionnement effectif de ce dernier en examinant les logs
• tester

host srv1.domaine.lan    : résultat ?

host poste1.domaine.lan  : résultat ?

host srv1     : resultat ?

host poste1   : résultat ? 

host 192.168.1.1   : resultat ?

host 192.168.1.100   : résultat ?

host -l domaine.lan : résultat ?

host -t soa domaine.lan : résultat ?

host google.com : resultat ?

Il est nécessaire de spécifier un ou plusieurs serveurs (forwarder) pour la redirection (on pourra utiliser ceux du lycée).

Le paramètre à changer est le suivant dans le fichier /etc/bind/named.conf.options (à adapter aux conditions locales):

 forwarders {
             1.2.3.4;  ici forwarder 1
             5.6.7.8;  ici forwarder 2
        };

Et mettre à no dnssec-validation (pour une éventuelle certification)

Une fois effectué le changement, relancer le démon bind puis tester à nouveau la résolution.

Il pourra être intéressant d'examiner les requêtes DNS sortantes avec :

   tcpdump port 53

host google.com     : resultat ?

Après avoir vérifié la configuration du client Windows (serveur DNS, nom de domaine DNS), tester la résolution de noms dans les mêmes conditions.

• installer les mêmes paquetages sur la machine srv2 (192.168.1.2)
• sur le maître (srv1), dans les fichier de zone directe et inverse, ajouter un enregistrement NS correspondant au 2ème serveur DNS (srv2) ainsi que l'enregistrement A correspondant.
• Sur le maitre, relancer bind
• l'esclave doit disposer d'un fichier /etc/bind/named.conf.local dans lequel on définit les zones esclaves et les adresses du serveur maître pour récupérer les fichiers de zone.
• le plus simple est de récupérer celui du serveur maitre et de la tranferer sur l'esclave avec la commande scp. On peut alors l'éditer pour obtenir :

  	// zone directe
          zone "domaine.lan" {
               type slave;
               file "/etc/bind/db.domaine.lan";
  	     masters { 192.168.1.1; };
  
          };
  
  	// zone inverse 
  	zone "1.168.192.in-addr.arpa" {
  	     type slave;
               notify no;
               file "/etc/bind/db.domaine.lan.rev";
  	     masters { 192.168.1.1; };
  
  	};

Depuis la version 9.9 de bind, les fichiers de zone sont transférés vers les esclaves au format binaire de façon à améliorer les performances.

En conséquence, il n'est plus possible d'afficher ou d'éditer les fichiers de zone de l'esclave.

Pour revenir au comportement initial (fichiers de zone au format texte), on pourra ajouter la clause masterfile-format text dans le fichier named.conf.local

 
           zone "domaine.lan" {
               type slave;
               file "/etc/bind/db.domaine.lan";
  	       masters { 192.168.1.1; };
               masterfile-format text;
          };

Depuis l'esclave :

Vérifier que le fichier resolv.conf contienne les élements suivants :

search domaine.lan
server 127.0.0.1   # on résoud localement

• relancer le démon bind
• vérifier dans les logs le transfert effectif des fichiers de zone ainsi que la présence des fichier db. dans le répertoire /etc/bind
• en cas de problème de transfert, vérifier les droits en écriture du démon bind dans le répertoire /etc/bind. Au besoin, les adapter avec la commande chmod. Dans ce cas, relancer le démon bind puis vérifier la présence des fichiers db : le transfert doit être pris en charge par les serveurs DNS hors de toute intervention humaine. on doit éditer le fichier /etc/apparmor.d/usr.sbin.named et changer les droits pour le répertoire /etc/bind :

  /etc/bind/** rw,

• on doit alors relancer le service apparmor
• on peut alors tester la résolution de noms dans les mêmes conditions que précedemment.

• Modifier le paramétrage du client Windows pour lui indiquer l'existence de deux serveurs DNS.
• couper le serveur maître
• tester la résolution depuis le client Windows (locale et hors zone)
• conclusion

• tester les ACL pour le transfert de zone et les requêtes en restreignant les transferts et les requêtes