Intéressé par des cours d'informatique en ligne ?
Visitez mon nouveau site
https://www.yesik.it !
BIND – Berkeley Internet Name Daemon – est le serveur DNS le plus répandu dans le monde Unix ... et dans le monde en général. Si vous avez à administrer un parc, même modeste, d'ordinateurs, un jour ou l'autre vous aurez besoin de travailler avec. Voyons donc comment installer BIND sous Debian. Bien entendu, au delà de la simple installation, nous allons surtout voir comment configurer une zone pour gérer les machines de votre réseau local...
Sommaire
Installation
Joie et bonheur: BIND est disponible dans le paquet Debian bind9. L'installation se résume donc à sa plus simple expression:
dns-server:~# apt-get install bind9
Au passage, l'installation a non seulement copié les fichiers nécessaires, mais aussi lancé named(8), le serveur DNS de BIND.
dns-server:~# ps -edf | grep named bind 1583 1 0 13:39 ? 00:00:00 /usr/sbin/named -u bind root 1872 1064 0 14:10 tty0 00:00:00 grep named
Le serveur est lancé avec une configuration standard minimum, mais il est d'ores et déjà possible de l'interroger, par exemple avec nslookup(8), le client standard de BIND disponible dans le paquet dnsutils:
buckaroo@labo:~$ nslookup localhost 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 Name: localhost Address: 127.0.0.1

Piège:
A moins que son nom ne puisse être résolu par un autre moyen sur votre système (via /etc/hosts par exemple), vous devez désigner le serveur DNS par son adresse IP. Dans mon cas 10.129.37.204.
buckaroo@labo:~$ nslookup 127.0.0.1 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 1.0.0.127.in-addr.arpa name = localhost.
Ok, rien de très excitant: on arrive à retrouver l'adresse de localhost. Et inversement le nom de la machine derrière 127.0.0.1. Si l'utilité de passer par un serveur DNS pour obtenir cette information est douteuse, au moins, nous savons que le serveur tourne et est accessible. Avant de passer à la phase de configuration de nos propres zones, vérifions tout de même que notre serveur DNS est capable de rechercher d'autres noms dans l'espace de nommage:
buckaroo@labo:~$ nslookup www.google.com 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 Non-authoritative answer: www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 173.194.33.104
Dans ma zone...
Pour cet article, je vais considérer l'installation d'une zone DNS non accessible de l'extérieur. Cela pourrait être par exemple le cas de la gestion des machines situées sur votre intranet. Celles-ci doivent pouvoir se localiser les unes les autres. Sans pour autant qu'il soit nécessaire de résoudre leur nom à partir de l'extérieur. Ici, nous allons nous appuyer sur l'intranet de l'Intitut Banzai, et en conséquence configurer la zone banzai-institute.intra.
Sous Debian, le fichier de configuration de named est éclaté en plusieurs parties. Normalement, les modifications locales sont à faire dans /etc/bind/named.conf.local. Ici, j'ajoute une zone pour laquelle notre serveur doit être maître:
dns-server:~# cat >> /etc/bind/named.conf.local << EOF zone "banzai-institute.intra" { type master; file "/etc/bind/db.banzai-institute.intra"; }; EOF
Résolution directe
Comme vous le voyez dans la configuration précédente, les informations sur la zone sont déportées dans le fichier /etc/bind/db.banzai-institute.intra. Dans le format DNS, la résolution directe (dans le sens nom vers adresse IPv4) se fait avec un enregistrement A (et un enregistrement AAAA pour une adresse IPv6).
Mis à part un en-tête qui définit l'origine ($ORIGIN) et la durée de vie par défaut des informations ($TTL), le fichier de zone contient les enregistrements pour les informations disponibles dans mon DNS. Ici, j'utilise 3 types d'enregistrements différents:
- SOA
- Start Of Authority – cet enregistrement contient les informations relatives à la zone. Le @ est un raccourci pour dénoter l'origine ($ORIGIN);
- NS
- Name Server – Indique un serveur de nom pour la zone désignée;
- A
- Address (IPv4) – Fait correspondre un nom d'hôte à une adresse IPv4.
En supposant que je ne veuille gérer dans ma zone que trois hôtes, voici, ce que cela pourrait donner.
dns-server:~# cat /etc/bind/db.banzai-institute.intra ; ; Banzai Institute intranet ; $ORIGIN banzai-institute.intra. $TTL 604800 @ IN SOA dns-server.banzai-institute.intra. sylvain.chicoree.fr. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS dns-server.banzai-institute.intra. ; dns-server.banzai-institute.intra. IN A 10.129.37.204 labo.banzai-institute.intra. IN A 10.129.37.202 jetcar.banzai-institute.intra. IN A 10.129.37.201

Piège:
Ici, mes noms d'hôtes sont absolus. Il ne faut pas oublier d'ajouter le point terminal dans banzai-institute.intra.!
De manière plus compacte, j'aurais pu utiliser des noms relatifs. C'est à dire sans le point terminal. Dans ce cas, le DNS ajoute automatiquement l'origine à la fin des noms. Ce qui permet d'écrire de manière plus compacte:
; ; Banzai Institute intranet ; $ORIGIN banzai-institute.intra. $TTL 604800 @ IN SOA dns-server sylvain.chicoree.fr. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS dns-server ; dns-server IN A 10.129.37.204 labo IN A 10.129.37.202 jetcar IN A 10.129.37.201

Remarque:
Le second nom dans l'enregistrement SOA (sylvain.chicoree.fr dans mon exemple) est en réalité une l'adresse e-mail du responsable de la zone!
@ IN SOA dns-server sylvain.chicoree.fr. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
Adresse e-mail | |
---|---|
Format DNS | Format standard |
sylvain.chicoree.fr. | sylvain@chicoree.fr |
Comme tous les noms dans le fichier de zone, cette adresse peut être absolue (elle est terminée par un point) ou relative par rapport à l'origine (non terminée par un point). Une fois l'adresse absolue obtenue, on peut convertir cette adresse e-mail au format habituel en remplaçant le premier point par un @.
Après modification, il est souhaitable de recharger la configuration. Avec BIND9, on peut utiliser l'utilitaire rndc(8):
dns-server:~# rndc reload server reload successful
On peut s'assurer du fonctionnement de la résolution à partir d'un client:
buckaroo@labo:~$ nslookup jetcar.banzai-institute.intra 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 Name: jetcar.banzai-institute.intra Address: 10.129.37.127
buckaroo@labo:~$ nslookup -type=any banzai-institute.intra 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 banzai-institute.intra origin = dns-server.banzai-institute.intra mail addr = sylvain.chicoree.fr serial = 2 refresh = 604800 retry = 86400 expire = 2419200 minimum = 604800 banzai-institute.intra nameserver = dns-server.banzai-institute.intra.
Résolution inverse
Super, ça marche. Et en moins de 5 minutes (ou peu s'en faut). Sauf que:
buckaroo@labo:~$ nslookup 10.129.37.202 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 ** server can't find 202.37.129.10.in-addr.arpa.: NXDOMAIN
La requête précédente est supposée retrouver le nom d'une machine à partir de son adresse IP. Ça n'est pas un gadget, car c'est une fonctionnalité utilisée par de nombreux services pour mettre un nom sur une adresse IP. Bien que faible, c'est même quelques fois un mécanisme utilisé pour faire du contrôle d'accès...
La solution consiste à ajouter une autre zone à notre DNS. Correspondant au sous réseau 10. Ou 10.129. Ou 10.129.37. L'idée étant juste d'avoir une zone qui couvre le préfixe de sous-réseau utilisé sur votre LAN. Et comment fait-on cela? Observez mieux le résultat de la résolution inverse:
buckaroo@labo:~$ nslookup 10.129.37.202 10.129.37.204
Server: 10.129.37.204
Address: 10.129.37.204#53
** server can't find 202.37.129.10.in-addr.arpa.: NXDOMAIN
Et oui! La solution est écrite dans le message d'erreur: le DNS cherche l'information dans l'enregistrement 202.37.129.10.in-addr.arpa. C'est l'adresse IP à l'envers, juste suivi du suffixe .in-addr.arpa.. Ce qui nous donne trois zones possibles:
- 10.in-addr.arpa
- 129.10.in-addr.arpa
- 37.129.10.in-addr.arpa
Comme mon DNS n'est supposé gérer que le sous-réseau 10.129.37.0, c'est cette dernière option que j'ai choisi:
dns-server:/etc/bind# cat >> named.conf.local << EOF zone "37.129.10.in-addr.arpa" { type master; file "/etc/bind/db.10.129.37"; }; EOF
Et comme tout à l'heure, la base de données des adresses est déportée dans un fichier séparé:
dns-server:/etc/bind# cat db.10.129.37 ; ; Banzai Institute intranet ; (reverse) ; $ORIGIN 37.129.10.in-addr.arpa. $TTL 604800 @ IN SOA dns-server.banzai-institute.intra. sylvain.chicoree.fr. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS dns-server.banzai-institute.intra. ; 204 IN PTR dns-server.banzai-institute.intra. 202 IN PTR labo.banzai-institute.intra. 201 IN PTR jetcar.banzai-institute.intra.
Le format de fichier est sensiblement le même que pour la résolution directe. A l'exception de l'utilisation d'enregistrements PTR à la place des enregistrements A. Ceux-ci font correspondre une adresse IP à un nom. Prenons un exemple:
$ORIGIN 37.129.10.in-addr.arpa. ...' 202 IN PTR labo.banzai-institute.intra.
Comme vous le remarquez, le 202 n'est pas suivi par un point. C'est donc un nom relatif à l'origine. Cet enregistrement est donc équivalent à:
202.37.129.10.in-addr.arpa. IN PTR labo.banzai-institute.intra.
Lors d'une résolution inverse, l'adresse IP est inversée et le suffixe in-addr.arpa est ajouté. Autrement dit, cet enregistrement fait correspondre l'adresse IPv4 10.129.37.202 au nom labo.banzai-institute.intra.
Mais assez de théorie: pour vérifier en pratique que cela fonctionne, il nous fait d'abord recharger la configuration dans le serveur:
dns-server:/etc/bind# rndc reload server reload successful
Et voilà:
buckaroo@labo:~$ nslookup 10.129.37.202 10.129.37.204 Server: 10.129.37.204 Address: 10.129.37.204#53 202.37.129.10.in-addr.arpa name = labo.banzai-institute.intra.
Configurer le client
Reste à configurer chaque client. Rien de spécifique au fait que ce soit notre DNS. Sous Linux/Debian cette configuration prend place dans le fichier /etc/resolv.conf:
labo:~# cat > /etc/resolv.conf << EOF nameserver 10.129.37.204 domain banzai-institute.intra EOF
Avec cette configuration, non seulement j'ai désigné l'adresse IP du serveur DNS. Mais aussi, j'ai précisé le domaine par défaut. C'est le domaine qui sera testé lors de la résolution des noms d'hôte non qualifiés:
# Avec le domaine par défaut, "jetcar" est résolut comme "jetcar.banzai-institute.intra" buckaroo@labo:~$ nslookup jetcar Server: 10.129.37.204 Address: 10.129.37.204#53 Name: jetcar.banzai-institute.intra Address: 10.129.37.201
Et maintenant
Cette installation expresse de BIND est terminée. C'est peut-être suffisant pour un tout petit réseau. Mais si vous envisagez quelque-chose de plus sérieux, il faudra sans doute envisager un serveur esclave au cas ou le maître serait inaccessible. Ou encore déployer un esclave sur les différents sous-réseaux de votre réseau d'entreprise pour limiter le trafic sur le routeur central.
Par ailleurs, je tiens à vous faire remarquer que le serveur DNS reste un système critique autant sur un intranet que sur Internet. Et que finalement, rien ne prouve en l'état l'authenticité des réponses fournies: vous l'avez vu, c'est facile d'installer un serveur DNS. Et qu'est-ce qui se passerait si un serveur pirate se retrouvait sur votre réseau?
Ressources
- (en) Paul Albitz, Cricket Liu. DNS and BIND (livre). O'Reilly, 2006. ISBN 0596100574.