BIND (Berkely Internet Name Domain) est un serveur DNS open source utilisé pour la résolution de noms Internet.

Objectif : installer un serveur BIND pas à pas à partir des sources officielles afin de s'en servir pour porter une zone Internet (serveur autoritaire) ou pour effectuer du cache DNS (serveur cache seulement).

Logiciel utilisé : BIND 9.7.2-P3

Système d'exploitation : Debian 5.0, Linux 2.6.34

---

1 – Pré-requis

Des outils de compilation : make et gcc, ainsi que gnupg pour la vérification du package. Etant sur Debian, j'utilise apt-get pour les récupérer

$ apt-get install gcc make gnupg


Je vous invite à vous rendre sur cette page pour récupérer le lien de la dernière version stable de Bind : https://www.isc.org/downloadables/11

Et on récupère le package qui va bien, avec sa signature :

$ cd ~
$ wget http://ftp.isc.org/isc/bind9/9.7.2-P3/bind-9.7.2-P3.tar.gz
$ wget http://ftp.isc.org/isc/bind9/9.7.2-P3/bind-9.7.2-P3.tar.gz.asc


2 – Vérifier le package

Avant d'aller plus loin, il faut s'assurer que le package est authentique, c'est à dire qu'il n'a pas été détourné par un tiers.

L'authenticité du package se vérifie grâce au programme gnupg, qui va vérifier la signature du package (fichier bind*.asc) avec une des clés publique présente sur le site de Bind.

On va donc télécharger la clé publique disponible sur le site de Bind, à cette adresse : http://www.isc.org/about/openpgp

$ wget http://www.isc.org/files/pgpkey2009.txt

On importe ensuite la clé et on vérifie le package :

$ gpg --import pgpkey2009.txt
gpg: clé 0B7BAE00: clé publique « Internet Systems Consortium, Inc. (Signing key, 2009) <pgpkey2009@isc.org> » importée
gpg:        Quantité totale traitée: 1
gpg:                       importée: 1  (RSA: 1)
gpg: aucune clé de confiance ultime n'a été trouvée
$ gpg --verify bind-9.7.2-P3.tar.gz.asc bind-9.7.2-P3.tar.gz
gpg: Signature faite le mer 01 déc 2010 03:24:16 CET avec la clé RSA ID 0B7BAE00
gpg: Bonne signature de « Internet Systems Consortium, Inc. (Signing key, 2009) <pgpkey2009@isc.org> »
gpg: ATTENTION: Cette clé n'est pas certifiée avec une signature de confiance !
gpg:            Rien ne dit que la signature appartient à son propriétaire.
Empreinte de clé principale: FA76 7A86 A371 E359 22F6  A5C8 D811 B53F 0B7B AE00

Le "ATTENTION" indique simplement que la clé utlisée n'est pas certifiée par un tiers de confiance. Si vous n'avez pas confiance, vous pouvez toujours contacter la personne par téléphone pour s'assurer avec elle que vous possédez bien sa clé … (sisi !)

3 – Compiler et installer

Une fois le package de BIND récupéré et vérifié on le décompresse dans le répertoire /usr/local/src :

$ tar xvzf bind-9.7.2-P3.tar.gz -C /usr/local/src
$ cd /usr/local/src/bind-9.7.2-P3/

On peut maintenant configurer, compiler et installer en spécifiant deux options :

• --prefix : chemin d'installation
• --datarootdir : répertoire de données, où sont notamment stockées les pages de man

$ ./configure --prefix=/usr/local/bind --datarootdir=/usr/share
$ make && make install


Voilà, c'est installé !

4 – Modifier le PATH

Afin de pouvoir utiliser les commandes fournies par BIND (comme nslookup) sans avoir à retaper toute l'arborescence, nous allons modifier la variable PATH des utilisateurs :

$ echo -e "bind=/usr/local/bind/bin\nPATH=\$PATH:\$bind" >> /etc/profile $ . /etc/profile

5 – Configurer le serveur Bind

5.1 – Généralités

La configuration du serveur BIND se fait dans le fichier named.conf, que l'on va créer dans /usr/local/bind/etc. La configuration se compose généralement de deux parties : les options du serveur et la définition des différentes zones.

On peut déjà remplir ce fichier de manière générique :

$ cd /usr/local/bind/etc
$ vi named.conf

// options du serveur
options {
        directory "/usr/local/bind/var";        // repertoire de travail
};

// zone inverse pour la boucle locale
zone "0.0.127.in-addr.arpa" {
        type master;            // on est maitre sur la zone
        file "localhost.rev";   // nom du fichier de zone
        notify no;              // pas de notification
};

On a juste indiqué le répertoire de travail, qui contiendra les fichiers de zone, et nous avons défini la zone 0.0.127.in-addr.arpa, correspondant à la zone inverse localhost. La zone définie contient un fichier de zone que l'on va créer dans /usr/local/bind/var :

$ cd /usr/local/bind/var
$ vi localhost.rev

$TTL    1D
$ORIGIN 0.0.127.in-addr.arpa.
@       IN      SOA      localhost.      root.localhost.      (
                     2010022001         ; Serial
                             8H         ; Refresh
                            15M         ; Retry
                             1W         ; Expire
                             1D )       ; Negative Cache TTL
;
        IN      NS      localhost.
1       IN      PTR     localhost.

Ce fichier contient un certain nombre de RR, Resource Record. Ici trois : SOA, NS et PTR.

Quelques explications s'imposent :

• $TTL : indique la durée de vie d'un enregistrement. Paramètre important pour le cache des serveurs DNS
• $ORIGIN : nom de la zone : optionnel, permet de ne pas avoir à écrire la zone plusieurs fois dans le fichier
• SOA : Star Of Authority. Resource record indiquant le serveur gérant la zone (localhost.), l'administrateur (root.localhost., correspondant à root@localhost.), la version (Serial), ainsi que diverses options utilisées par les serveurs esclaves
• NS : nom du serveur maitre de la zone
• PTR : résolution inverse. Permet de résoudre ici 127.0.0.1 en localhost

5.2 – Serveur cache seulement

Le but d'un serveur "cache seulement" est de répondre aux requêtes qui lui sont adressés et de les mettre en cache. De cette façon, si la prochaine fois que la requête lui est adressée, il répondra beaucoup plus rapidement puisqu'il aura déjà la réponse (dans la limite du TTL de la réponse).

Ce type de configuration est généralement utilisée pour servir de serveur DNS principal dans un réseau local, comme un réseau d'entreprise. Elle peut également être utilisée chez soi pour accélérer la navigation.

5.2.1 – Configuration

On va juste ajouter quelques lignes à notre fichier de configuration de départ :

$ cd /usr/local/bind/etc
$ vi named.conf

// definition d'une access list
acl monreseau { 127.0.0.1/32; 192.168.0.0/24; };

// options du serveur
options {
        directory "/usr/local/bind/var";        // repertoire de travail
        allow-query { monreseau; };             // qui est autorise a envoyer des requetes
};

// zone inverse pour la boucle locale
zone "0.0.127.in-addr.arpa" {
        type master;            // on est maitre sur la zone
        file "localhost.rev";   // nom du fichier de zone
        notify no;              // pas de notification
};

Ces ajouts permettent d'indiquer qui à le droit de requêter le serveur. Permet de contrôler les flux entrants, et donc la charge du serveur qui ne sera pas utilisée pour d'autre machines que celles à qui le serveur BIND est destiné.

5.2.2 – Démarrage et test

On peut maintenant effectuer le lancement du serveur BIND. On lui indique en option le fichier de configuration utilisé :

# /usr/local/bind/sbin/named -c /usr/local/bind/etc/named.conf

On vérifie que le process named est bien présent

# ps -ef | grep named
root     13951     1  0 23:01 ?        00:00:00 /usr/local/bind/sbin/named -c /usr/local/bind/etc/named.conf

Si le processus n'apparaît pas, il faut consulter le fichier de log (sous Debian : /var/log/daemon.log) qui est plutôt verbeux et indiquera rapidement d'où vient le problème (erreur dans le fichier de configuration, par exemple).

Nous pouvons ensuite tester le bon fonctionnement de la résolution de nom grâce aux outils fournis par BIND, à savoir dig et nslookup. On précise à ces commandes que l'on souhaite résoudre grâce à notre propre serveur DNS, c'est à dire localhost :

$ dig @localhost www.test.com

; <<>> DiG 9.7.2-P3 <<>> @localhost www.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41189
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.test.com.                  IN      A

;; ANSWER SECTION:
www.test.com.           7200    IN      A       204.12.0.50

;; AUTHORITY SECTION:
test.com.               172800  IN      NS      ns66.worldnic.com.
test.com.               172800  IN      NS      ns65.worldnic.com.

;; Query time: 271 msec
;; SERVER: localhost#53(localhost)
;; WHEN: Sun Dec 19 23:28:10 2010
;; MSG SIZE  rcvd: 93


$ nslookup
> server localhost
Default server: localhost
Address: localhost#53
> www.test.com
Server:         localhost
Address:        localhost#53

Non-authoritative answer:
Name:   www.test.com
Address: 204.12.0.50
> exit

Ces deux commandes nous retournent bien l'adresse IP à partir d'un nom, avec des informations complémentaires plus ou moins détaillées selon la commande utilisée.

5.2.3 – Configuration des clients

Pour utiliser ce serveur depuis les autres machines du réseau, il ne reste plus qu'à renseigner l'adresse IP de notre serveur DNS dans le fichier /etc/resolv.conf des machines :

$ vi /etc/resolv.conf


nameserver 192.168.0.250

Ce fichier permet de recenser les serveurs DNS à consulter automatiquement pour toute résolution de noms. Il n'est par exemple plus nécessaire ensuite de spécifier le serveur lorsqu'on exécute dig ou nslookup.

5.3 – Serveur autoritaire sur une zone Internet (publique)

Nous voulons maintenant créer notre propre zone Internet que nous nommerons mondomaine.fr, qui sera portée par notre serveur BIND fraichement installé. Cette zone doit donc être visible depuis tout l'Internet puisque c'est une zone publique. Elle permettra ensuite de déclarer des noms du type www.mondomaine.fr, qui seront accessibles pour tout le monde. Ce qui est bien sur plus pratique que de taper une adresse IP pour accéder à un site Web …

Ce serveur fera donc autorité sur la zone créée, on dira qu'il est autoritaire ou maître.

5.3.1 – Ports

Le serveur BIND utilise le port 53 en UDP et TCP pour l'émission et la réception des requêtes.

Il faut donc penser à ouvrir ces ports au niveau d'un éventuel pare-feu pour tout le monde, dans les deux sens.

5.3.2 – Configuration

On va ajouter certaines options au serveur ainsi que la zone que nous voulons créer dans le fichier de configuration de départ (cf. 5.1)

$ cd /usr/local/bind/etc
$ vi named.conf

options {
        directory "/usr/local/bind/var";        // repertoire de travail
        allow-query-cache { none; };            // personne n'accède au cache
        allow-query { any; };                   // tout le monde peut requeter le serveur
        recursion no;                           // pas de recursivité
};

// zone inverse locale
zone "0.0.127.in-addr.arpa" {
        type master;            // on est master sur la zone
        file "localhost.rev";   // fichier de zone
        notify no;              // pas de notification
};

// on est autoritaire sur mondomaine.fr
zone "mondomaine.fr" {
        type master;
        file "mondomaine.fr.db";
};

Les options ajoutées permettent de s'assurer que tout l'Internet puisse requêter le serveur mais uniquement pour notre nouvelle zone. Ceci afin d'éviter que notre serveur ne serve de cache à tout l'Internet …

Nous avons déclaré la zone mondomaine.fr sur laquelle nous sommes autoritaires. Charge à nous de créer le fichier de zone correspondant :

$ cd /usr/local/bind/var
$ vi mondomaine.fr.db


$TTL    1D
$ORIGIN mondomaine.fr.
@       IN      SOA      server      root      (
                     2010022001         ; Serial
                             8H         ; Refresh
                             4H         ; Retry
                             4W         ; Expire
                             1D )       ; Negative Cache TTL

; serveurs de noms
                NS      server
                NS      server2

; quelques alias utiles
www             CNAME   server
ftp             CNAME   server

; noms des machines du domaine
server          A       12.123.34.23
server2         A       12.123.34.24

Comme dans le fichier de zone vu précédemment, on a défini plusieurs Resource Record.

L'option $ORIGIN permet d'écrire dans le fichier server ou root au lieu de leur FQDN (Full Qualified Domain Name) : server.mondomaine.fr ou root.mondomaine.fr.

On définit ensuite le ou les serveurs portant la zone (RR NS, ici server et server2).

On inclut également des CNAME, qui sont en fait des alias pointant sur une vraie machine. Ici, le fait de requêter www.mondomaine.fr renverra server.mondomaine.fr.

Enfin, on définit des RR A, c'est à dire un nom correspondant à une adresse IP. Il doit y avoir au minimum les machines décrites en tant que SOA, NS et CNAME.

5.3.3 – Redémarrage et tests

On peut maintenant redémarrer BIND pour prendre en compte notre nouvelle configuration. On tue le process existant, puis on relance BIND :

$ kill `cat /usr/local/bind/var/run/named/named.pid`
$ /usr/local/bind/sbin/named -c /usr/local/bind/etc/named.conf


On vérifie que le process named est bien présent :

$ ps -ef | grep named
root     13951     1  0 23:01 ?        00:00:00 /usr/local/bind/sbin/named -c /usr/local/bind/etc/named.conf

On peut maintenant faire quelques tests de résolution de noms à l'aide des commandes dig et nslookup (fournies avec le package) :

$ dig @localhost server.mondomaine.fr

; <<>> DiG 9.7.2-P3 <<>> @localhost server.mondomaine.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1730
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;server.mondomaine.fr.       IN      A

;; ANSWER SECTION:
server.mondomaine.fr. 86400  IN      A       10.232.36.24

$ nslookup
> server localhost
Default server: localhost
Address: 127.0.0.1#53
> server.mondomaine.fr
Server:         localhost
Address:        127.0.0.1#53

Name:   
server.mondomaine.fr
Address: 10.232.36.24
> exit

Ces tests peuvent également être effectués à partir d'une machine distante (en remplaçant localhost par l'adresse IP de la machine) afin de vérifier que la résolution sera possible pour tout le monde.

5.3.4 – ZoneCheck

Si vous utilisez un nom de domaine en .fr, il faudra passer par une vérification du service DNS que vous avez configurer avant de pouvoir déclarer votre serveur au niveau du registrar (organisme auprès duquel vous avez souscrit le nom de domaine, et qui va permettra aux serveurs DNS du monde entier d'accéder à votre zone, pour répondre à un client qui souhaiterait par exemple accéder à www.mondomaine.fr).

Cette vérification est effectuée par l'outil ZoneCheck, disponible ici : http://www.afnic.fr/outils/zonecheck. Cet outils effectue un certain nombre de tests portant sur plusieurs dizaines de critères tels que la présence d'un serveur DNS secondaire pour votre zone ou le bon calibrage des temps de mise à jour des serveurs esclaves (valeurs en en-tête du fichier de zone, après le serial).

A la suite de ces tests, un certain nombre de recommandations peuvent être faites, avec un statut de WARNING ou FATAL. La correction des recommandations FATAL est obligatoire pour qui veut mettre à disposition son serveur DNS, et donc sa zone, sur l'Internet. Ceci afin de garantir une certaine qualité dans la configuration des noms de domaine en .fr.

6 – Démarrage automatique

6.1 – Création du script

Après avoir installé et configuré notre serveur BIND, on va maintenant faire en sorte qu'il démarre tout seul à chaque redémarrage de la machine.

La première étape est la création d'un petit script shell que l'on utilisera pour démarrer, arrêter, recharger la configuration ou vérifier le statut du serveur. On positionnera ce script avec les autres scripts de démarrage dans /etc/init.d.

$ vim /etc/init.d/named


#!/usr/bin/ksh

daemon="named"
conf="/usr/local/bind/etc/named.conf"
cmd="/usr/local/bind/sbin/named"

case $1 in
        "start")
                $cmd -c $conf
                if [[ $? == 0 ]]
                then
                        echo "$daemon is running now"
                        exit 0
                else
                        echo "failed of running $daemon !!!"
                        exit 1
                fi
        ;;
        "stop")
                kill -TERM `cat /usr/local/bind/var/run/named/${daemon}.pid`
                if [[ $? == 0 ]]
                then
                        echo "$daemon is stopped"
                        exit 0
                else
                        echo "failed of stopping $daemon !!!"
                        exit 1
                fi
        ;;
        "status")
                if [[ -f /usr/local/bind/var/run/named/${daemon}.pid ]] && [[ `ps -ef | grep $cmd | grep -vc grep` -ge 1 ]]
                then
                        echo "$daemon is running"
                        exit 0
                else
                        echo "$daemon is stopped"
                        exit 1
                fi
        ;;
        "reload")
                kill -HUP `cat /usr/local/bind/var/run/named/${daemon}.pid`
                if [[ $? == 0 ]]
                then
                        echo "$daemon is reloaded"
                        exit 0
                else
                        echo "failed of reloading $daemon !!!"
                        exit 1
                fi
        ;;
        *)
                echo "Usage : $0 start|stop|reload|status"
                exit 1
        ;;
esac

On positionne les droits d'exécution sur le fichier, pour le propriétaire uniquement (en l'occurence, root) :

# chmod 755 /etc/init.d/named


Le script s'utilisera de la façon suivante :

# /etc/init.d/named
Usage : /etc/init.d/named start|stop|reload|status


6.2 – Lancement automatique du script

Pour démarrer et arrêter automatiquement le serveur BIND, il faut créer des liens vers le script créé précédemment dans les différents niveaux d'exécution. Pour cela nous utiliserons le programme update-rc.d qui créera les liens correspondants aux niveaux demandés : (les liens pourraient tout aussi bien être créés à la main, c'est juste plus long)

$ update-rc.d named defaults
 Adding system startup for /etc/init.d/named ...
   /etc/rc0.d/K20named -> ../init.d/named
   /etc/rc1.d/K20named -> ../init.d/named
   /etc/rc6.d/K20named -> ../init.d/named
   /etc/rc2.d/S20named -> ../init.d/named
   /etc/rc3.d/S20named -> ../init.d/named
   /etc/rc4.d/S20named -> ../init.d/named
   /etc/rc5.d/S20named -> ../init.d/named

Dorénavant le serveur BIND s'arrêtera et démarrera proprement lors du redémarrage du système.