Comment faire une configuration complète d'un serveur DNS BIND9 avec un nom d'hôte ?

Réponse n'est qu'un complément à l'excellente description ci-dessus.

Conseil de dépannage

Faites très attention aux nombreux '.' dans les fichiers de configuration car chacun d'entre eux est important. Un seul '.' manquant peut empêcher le serveur DNS de fonctionner. Vous ne devez pas compter sur des messages d'erreur clairs.

J'ai appris que c'est une bonne pratique d'utiliser un numéro de série plus parlant. Il est très important d'incrémenter le numéro de série chaque fois que la configuration est modifiée, par exemple lorsque de nouvelles entrées sont ajoutées. S'il n'est pas incrémenté, un DNS secondaire ne parviendra pas à synchroniser les nouveaux paramètres. Le format suggéré est le suivant YYYYMMDDss où ss est l'"ancien" numéro de série. Ainsi, lorsque vous incrémentez, vous devez incrémenter ss par +1 y définir la date à la date actuelle. J'ai trouvé cela très utile pour le dépannage de la configuration. Dans le syslog, vous voyez clairement la date et le numéro de série du fichier utilisé.

Dans Ubuntu 16.04, la modification de resolv.conf est dépréciée. Comme jdthood écrit dans son commentaire remplacer l'étape par la procédure suivante : - Modifier le fichier /etc/default/bind9 : le nouveau test devrait ressembler à ceci :

   # run resolvconf?
   RESOLVCONF=yes

   # startup options for the server
   OPTIONS="-u bind"

   # use this when you have trouble with IPV6
   #OPTIONS="-u bind -4"

voir le commentaire de pas-de-patch pour les problèmes d'IPV6.

• mettre un lien symbolique de /etc/resolv.conf dans /run/resolvconf/resolv.conf

   cd /etc
   sudo ln -s /etc/resolv.conf /run/resolvconf/resolv.conf

Configuration hors ligne

La configuration est exactement la même, et même un peu plus facile, puisque vous pouvez simplement sauter les sections de transfert. Elles n'ont pas besoin d'être présentes, il n'est donc pas nécessaire de modifier le fichier /etc/bind/names.con.options .

Réseaux de classe B

Quelques modifications mineures sont nécessaires pour que cela fonctionne pour les réseaux de classe B (avant tout commentaire, il n'y a aucune raison pour qu'un réseau local, même à la maison, ne soit pas un réseau de classe B au lieu d'un réseau de classe C). Dans cet exemple, j'utilise le numéro de réseau 172.20.x.x. (je pense que la notation formelle est 172.20.0.0. pour plus d'info, google rfc1918).

Utilisez la description de la première réponse, remplacez toutes les IPs 192.168.x.x par 172.20.x.x, utilisez pour le serveur l'IP 172.20.0.100 et modifiez les fichiers comme suit :

• le nom du fichier db.192 devient db.172 .

• le fichier named.conf.local obtient une section de zone inverse différente :

  zone "20.172.in-addr.arpe" {
  type master;
  file "/etc/bind/zones/db.172";
  }

• Le fichier des zones inversées se transforme en :

  ;
  ; BIND reverse data file for 172.20.x.x
  ;
  $TTL    604800
  @       IN      SOA     nefitari.autun.hom. webuser.autun.hom. (
               2017022102         ; more intuitive serial YYYYMMDDss, here ss=02
                   604800         ; Refresh
                    86400         ; Retry
                  2419200         ; Expire
                   604800 )       ; Negative Cache TTL
  
  ; note: the '@'was missing from in the initial description
  @       IN  NS  nefitari.autun.hom.    
  
  100.0   IN  PTR nefitari.autun.hom. 
  121.0   IN  PTR client1.autun.hom.
  130.0   IN  PTR client2.autun.hom.
  33.0    IN  PTR client3.autun.hom.

Le reste est identique.

J'espère que cela sera utile à quelqu'un.