Installation et configuration de Bind9

Installation de Bind9

# apt-get install bind9

Les fichiers de configuration de Bind se trouvent, comme on peut s’y attendre, dans /etc/bind.
La configuration se fait en deux temps. Nous devons tout d’abord déclarer à notre serveur quels seront les noms de domaine qu’il va devoir gérer, on appelle ça des zones. Ensuite, nous devrons configurer ces zones, grâce à un fichier de configuration par zones.

Configuration du serveur master

Déclaration des zones

Une zone se déclare de cette façon :

zone « reseau.fr » {
type master;
file « /etc/bind/db.reseau.fr »;
allow-transfer { 192.168.0.2; };
};

Le type indique si vous êtes master ou slave sur la zone, c’est-à-dire si c’est vous qui effectuez les mises à jour (master) ou si vous les recevez d’un autre serveur (slave).
File indique le fichier dans lequel sera configurée votre zone.
Allow-transfer indique le serveur qui pourra recevoir vos mises à jour. Bien entendu, cette directive n’existe que dans le cas d’un serveur master.

Vous pouvez vérifier la syntaxe du fichier named.conf grâce à la commande

named-checkconf /etc/bind/named.conf

Celle-ci nous sera de nouveau utile pour tester le format des fichiers de zone eux-mêmes
Passons maintenant à la configuration de notre zone.

Configuration de la zone du serveur master

On édite donc le fichier /etc/bind/db.reseau.fr. Afin d’avoir une configuration « basique », vous pouvez faire une copie de /etc/bind/db.local.

cp /etc/bind/db.local /etc/bind/db.reseau.fr
 vim /etc/bind/db.reseau.fr

Dans ce fichier de zone, nous allons indiquer des enregistrements. Il en existe de plusieurs types :

A : c’est le type le plus courant, il fait correspondre un nom d’hôte à une adresse IPv4 ;
AAAA : fait correspondre un nom d’hôte à une adresse IPv6 ;
CNAME : permet de créer un alias pointant sur un autre nom d’hôte ;
NS : définit le ou les serveurs DNS du domaine ;
MX : définit le ou les serveurs de mail du domaine ;
PTR : fait correspond une IP à un nom d’hôte. Il n’est utilisé que dans le cas d’une zone inverse, que nous verrons plus loin ;
SOA : donne les infos de la zone, comme le serveur DNS principal, l’adresse mail de l’administrateur de la zone, le numéro de série de la zone et des durées que nous détaillerons.
Il en existe d’autres mais pas forcément utiles ou intéressants pour ce cours.

Voici ce que donnera notre fichier de zone complet :

$TTL 604800 ; 1 semaine
$ORIGIN reseau.fr.
@ IN SOA ns1.reseau.fr. admin.reseau.fr. (
2013020905 ;serial
3600 ; refresh (1 hour)
3000 ; retry (50 minutes)
4619200 ; expire (7 weeks 4 days 11 hours 6 minutes 40 seconds)
604800 ; minimum (1 week)
)

@ IN NS ns1.reseau.fr.
@ IN NS ns2
@ IN MX 10 mx1
@ IN MX 20 mx2
ns1 IN A 192.168.0.1
ns2 IN A 192.168.0.2
mx1 IN A 192.168.0.3
mx2 IN A 192.168.0.4
tuto IN A 192.168.0.5
www IN A 192.168.0.6
blog IN CNAME www

Examinons chacune de ces informations.

La première info est un TTL (Time to Live). Quand quelqu’un va interroger votre serveur DNS pour obtenir des informations, ces informations vont être stockées en cache chez cette personne (dans la mémoire de son serveur DNS, pour éviter qu’il vienne nous réinterroger de nombreuses fois s’il a de nouveau besoin d’une information). Ce TTL est la durée pendant laquelle les informations sont conservées en cache. Ce délai passé, une nouvelle demande devra être faite au serveur. Le TTL est défini ici sur 1 semaine. En fonction de la fréquence de vos mises à jour, vous pouvez décider de baisser cette valeur pour que vos clients aient leurs informations à jour.

La deuxième info est la variable ORIGIN. Celle-ci est optionnelle. Vous voyez les petits @ plus loin ? Ces @ prennent la valeur de la variable ORIGIN. En l’absence de variable ils prendront la valeur du nom de votre zone défini dans le fichier named.conf (reseau.fr ici).

Vient ensuite notre premier enregistrement, c’est un enregistrement de type SOA (Start Of Authority). Le type SOA est suivi de deux informations. La première est le nom du serveur de domaine principal (master) et la seconde est l’adresse mail de l’administrateur du domaine (en remplaçant l’arrobase par un point). Suivent entre parenthèses différentes valeurs.

Le serial peut être comparé à un numéro de version de votre zone. Il doit être incrémenté à chaque modification. Cela indique à votre serveur que votre zone a été mise à jour et qu’il faut envoyer la notification à vos serveurs esclaves. Les best practices recommandent une syntaxe particulière pour le serial de la forme AAAAMMJJXX (où XX est la version du jour en question). Cela vous permet entre autres de savoir la date de la dernière mise à jour de votre zone.
Refresh est le temps au bout duquel les enregistrements sont stockés sur le serveur slave. Passer ce délai, le serveur slave demandera une nouvelle mise à jour au serveur master.
Retry est le temps qu’attendra le serveur slave dans le cas où le serveur master contacté n’est pas joignable pour faire un nouvel essai.
Expire est le temps pendant lequel le serveur slave continuera à essayer de contacter le serveur master.
Minimum est la durée minimale du cache ; elle est en général égale à Refresh.
Nous trouvons ensuite les enregistrements, du moins ceux qui nous intéressent !

Les enregistrements se découpent en 4 parties sur une ligne (parfois 5 pour des enregistrements spécifiques).
La première information, c’est l’hôte de votre domaine. Nous avons parlé du @ tout à l’heure qui est remplacé par la valeur de $ORIGIN (le cas échéant par le nom de votre zone). Notez qu’on peut ne rien mettre du tout si on veut parler du domaine entier. Rien, @, ou un nom de machine ou de sous-domaine au choix.
Le second, représente la classe. Ici, elle spécifie qu’il s’agit d’un enregistrement concernant Internet. Il existe d’autres valeurs mais elles ne sont pas utilisées, donc on met toujours IN.
Le troisième spécifie le type d’enregistrement dont on a détaillé les différents types précédemment.
Enfin, le dernier spécifie la valeur de l’enregistrement dépendant du type. Un type A attendra une adresse IP, un type PTR attendra un nom d’hôte, etc.
On trouve parfois, juste avant cette dernière valeur, un nombre qui indique le « poids » d’un enregistrement. On verra plus loin dans quel cas c’est utile.

On commence généralement par les enregistrements des serveurs gérant notre domaine et les services associés (le mail en l’occurrence). Dans notre cas il s’agit des types NS et MX. On utilise l’@ parce que ces enregistrements ne déterminent pas un hôte en particulier, mais bien le domaine entier.

@ IN NS ns1.reseau.fr.

Cette ligne se traduit donc par : « ns1.reseau.fr est un serveur de nom de domaine de reseau.fr »

J’attire votre attention sur le « . » situé à la fin de ns1.reseau.fr, car celui-ci est extrêmement important. Cette valeur doit être un FQDN et le FQDN contient le « . » représentant la racine du DNS. Si vous aviez écrit ns1.reseau.fr sans le « . », votre serveur aurait automatiquement rajouté à la fin le FQDN de votre zone, ce qui aurait donné ns1.reseau.fr.reseau.fr. ; ce qui n’a plus du tout la même valeur !
Ceci étant, réécrire à chaque fois le FQDN c’est un peu contraignant. Et comme on sait que, ne pas finir sa ligne par un « . » rajoute au FQDN de votre zone, on peut se permettre de n’écrire que « ns1 ». Ainsi, votre serveur rajoutera « reseau.fr. » et on aura le FQDN que l’on cherchait à obtenir.
Voyez la deuxième ligne qui utilise cette syntaxe raccourcie.

Les enregistrements MX utilisent la même syntaxe que pour les NS et indiquent l’adresse IP d’un serveur de messagerie, à cela près que nous avons rajouté un chiffre devant « mx1 ». Nous avons dit tout à l’heure que ce chiffre déterminait le « poids » d’un enregistrement, on parle aussi de priorité. Nous avons deux serveurs MX : mx1 et mx2 ; cette valeur va permettre de déterminer lequel des deux doit être utilisé en priorité. Plus elle est basse, plus le serveur est prioritaire.

Mais nous avons aussi deux serveurs NS ! Comment se passe cette priorité, étant donné qu’il n’y a pas de valeur pour les départager ?
Dans ce cas, c’est chacun son tour. Sur une machine Linux, essayez plusieurs fois de suite cette commande :

host -t NS google.fr

Vous verrez que les réponses que vous recevez ne sont jamais dans le même ordre. Cela s’appelle du Round-Robin, c’est une méthode qui permet d’équilibrer la charge entre les deux serveurs pour ne pas les surcharger, car un serveur sera autant consulté que les autres serveurs du même type.

Très bien, maintenant on sait que les serveurs mail de notre domaine sont mx1.reseau.fr et mx2.reseau.fr. Cependant, on ne sait toujours pas leurs adresses IP alors que c’est quand même le but d’un serveur DNS, non ?
D’ailleurs, vous voyez qu’ensuite nous définissons l’adresse IP de mx1 (sans . à la fin, donc mx1.reseau.fr ! ) avec un enregistrement de type A.
C’est ce qu’on appelle un Glue Record. On définit une première fois le nom d’hôte du serveur NS, puis on définit l’adresse IP de cet hôte. On doit faire cela, car un enregistrement NS associe un nom de serveur au nom du domaine. Il faut donc ajouter un enregistrement A pour le nom de ce serveur.

On retrouve ensuite les enregistrements les plus courants, ceux de type A (et AAAA quand on a de l’IPv6). En effet, le rôle principal du DNS est de faire correspondre un nom d’hôte avec son adresse IP, et c’est ce que fait le type A.
La syntaxe est relativement simple comme vous pouvez le voir :

tuto IN A 192.168.0.5

Comme pour les autres enregistrements, « tuto » ou « tuto.reseau.fr. » revient au même. N’oubliez pas le point si vous optez pour le FQDN.

Le type CNAME est aussi simple à comprendre. On fait correspondre un nom d’hôte à un autre nom d’hôte. Bien sûr, si « blog » pointe sur « www », l’enregistrement www doit exister.
Je le répète encore une fois : si vous choisissez le FQDN, n’oubliez pas le point, c’est une des premières causes d’erreurs dans les configurations DNS.

Voilà, notre zone est maintenant configurée sur notre serveur master. Vous devez redémarrer BIND pour que les changements soient pris en compte :

# /etc/init.d/bind9 restart

Vous pouvez vérifier la syntaxe du fichier de zone grâce à la commande suivante :

named-checkzone reseau.fr /etc/bind/db.reseau.fr.

Configuration du serveur slave

Nous avons prévu deux serveurs dans notre architecture . Celui que nous venons de configurer est le master ; celui que nous allons faire sera le slave. Les modifications se font sur le master, et celui-ci enverra des notifications aux slaves (il peut y en avoir plusieurs) pour que leurs zones soient mises à jour.

La configuration du serveur slave est donc relativement simple, tout se passe dans le named.conf. Il n’y a pas de fichier de zone à configurer étant donné que celui-ci sera reçu du master.

Si vous souhaitez tester complètement la mise en place du serveur DNS avec master et slave, vous pouvez tout à fait mettre en place le serveur slave sur une autre de vos machines virtuelles.
On commence par installer Bind comme pour le master et on édite /etc/bind/named.conf.

zone « reseau.fr » {
type slave;
file « /var/cache/bind/db.reseau.fr »;
masters { 192.168.0.1;};
};

La directive masters indique l’adresse IP du serveur master duquel nous allons recevoir les mises à jour de notre zone.

Résolution inverse

Pour l’instant, nous avons vu le protocole DNS comme un moyen de résoudre un nom d’hôte en une adresse IP. Nous avons parlé des enregistrements de type PTR et vous savez donc que DNS permet aussi de faire le travail inverse. C’est une résolution inverse.
Votre serveur DNS se doit de pouvoir résoudre une adresse IP en un nom d’hôte. C’est ce que nous allons faire ici.

Retournons dans notre fichier named.conf afin d’ajouter cette zone inverse. Nous allons déclarer la zone inverse de notre adressage IP, ici c’est 192.168.0.0/24.
Alors qu’une zone « normale » se déclare de façon plutôt logique, une zone inverse doit respecter une certaine forme concernant le nom de la zone :

zone « 0.168.192.in-addr.arpa. » {
type master;
file « /etc/bind/db.192.168.0 »;
};

Voilà pour la déclaration. Il faut juste faire attention au nommage de la zone, la partie réseau de l’adresse IP à l’envers, puis « .in-addr.arpa ».

On crée ensuite le fichier de zone.

$TTL 604800 ; 1 semaine
$ORIGIN 0.168.192.in-addr.arpa.
@ IN SOA ns1.reseau.fr. admin.reseau.fr. (
2013020905 ;serial
3600 ; refresh (1 hour)
3000 ; retry (50 minutes)
4619200 ; expire (7 weeks 4 days 11 hours 6 minutes 40 seconds)
604800 ; minimum (1 week)
)

@ IN NS ns1.reseau.fr.
@ IN NS ns2.reseau.fr.
1 IN PTR ns1.reseau.fr.
2 IN PTR ns2.reseau.fr.
3 IN PTR mx1.reseau.fr.
4 IN PTR mx2.reseau.fr.
5 IN PTR tuto.reseau.fr.
6 IN PTR www.reseau.fr.

Ce n’est pas très compliqué. C’est l’inverse d’une zone « normale ». Ça, je pense que vous l’avez compris maintenant. ^^
Les points auxquels il faut faire attention :

une zone inverse ne contient que des enregistrements de type NS ou PTR ;
dans notre zone « normale », blog redirigeait vers www, mais là une adresse IP ne peut pointer que vers un seul hôte ; la variable ORIGIN a changé ! Il faut donc penser à utiliser le FQDN de nos hôt‌es à chaque fois.

Vérification

On va quand même vérifier le fonctionnement de notre zone maintenant.
Commencez déjà par redémarrer votre serveur de nom pour prendre en compte les changements de configuration :# /etc/init.d/bind9 restart
Il existe plusieurs commandes pour faire des interrogations DNS. La commande la plus utilisée esthostmaisdigfournit plus d’informations et permet un diagnostic plus précis en cas de problème. Vérifiez d’abord le serveur DNS utilisé par votre machine. Comme cette machine est elle-même un serveur DNS, elle va devoir s’interroger elle-même.

Le programme qui fait toutes les résolutions DNS pour votre machine s’appelle le resolver. Ainsi, chaque programme qui a besoin de faire une résolution DNS s’adresse au resolver.
Son fichier de configuration se trouve dans /etc/resolv.conf qui doit au moins contenir l’adresse d’un serveur DNS à interroger :

nameserver 127.0.0.1

Oui, votre serveur va s’interroger lui-même. Vous pouvez spécifier d’autres serveurs, un par nameserver. Ce fichier peut aussi contenir des informations sur votre domaine ou le domaine de recherche.

On peut maintenant commencer nos tests :

Nous allons donc utiliser la commande host qui permet de faire une interrogation DNS.
Sa syntaxe est la suivante:
# host -t type nom_a_chercher IPserveur

On peut ainsi indiquer le type de la requête (NS, A, MX, CNAME, etc.), le nom à interroger, ainsi que l’adresse IP du serveur que l’on peut préciser.

Par exemple, si l’on cherche l’adresse des serveurs DNS du domaine reseau.fr :

# host -t ns reseau.fr
 reseau.fr name server ns1.reseau.fr.
 reseau.fr name server ns2.reseau.fr.

Et pour avoir leurs adresses IP:

# host -t a ns1.reseau.fr
ns1.reseau.fr has address 192.168.0.1
# host -t a ns2.reseau.fr
ns2.reseau.fr has address 192.168.0.2

Si tout se passe bien, c’est parfait. Dans le cas contraire, penser à vérifier que les syntaxes de vos fichiers de zones sont bonnes, avec « named-checkzone », et que vous avez bien pensé à relancer votre serveur Bind, etc.

Nous venons de voir que grâce à la commande host (ou dig), il est possible de demander toute information contenue dans vos zones DNS, ou même sur des serveurs situés sur Internet !

Exercice

Sachant que 8.8.8.8 est un serveur DNS public proposé par Google,

Trouvez les noms et adresses IP des 13 serveurs racine ;
trouvez la ou les adresses IP de www.siteduzero.fr ;
trouvez la ou les adresses IP de www.siteduzero.com ;
trouvez les adresses IP des serveurs DNS de lalitte.com.
Voici les requêtes à faire pour obtenir les réponses :

# host -t ns . 8.8.8.8

Faire ensuite une requête A pour chacun des serveurs racine :

# host -t a www.siteduzero.fr 8.8.8.8
# host -t a www.siteduzero.com 8.8.8.8
# host -t ns lalitte.com 8.8.8.8

Voilà, vous savez maintenant faire des interrogations DNS pour vérifier le fonctionnement de vos serveurs, ou de n’importe quel domaine sur Internet.

Vous avez vu comment mettre en place votre propre serveur DNS ainsi qu’un second serveur slave.
Vous savez gérer vous-mêmes votre propre nom de domaine.
Vous êtes familiarisés avec les concepts de zone, de résolution et de résolution inverse.

Félicitations, vous être prêts pour votre nouveau rôle d’administrateur systèmes et réseaux ! 😀

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *