Gérez vous même votre nom de domaine.

Bonjour,

Pour commencer ma série de billets tuto, je vais parler de ce qui facilite tout d’abord la gestion d’un réseau : le DNS. Est-il nécessaire de rappeler le fonctionnement de ce protocole, qui permet de résoudre une IP à partir d’un nom (largement plus facile à retenir) ? Non je ne pense pas. Au pire en voici le lien Wikipédia.

Afin de mettre en œuvre ce tuto, il vous faut un nom de domaine, et un registrar qui vous autorise à le gérer vous même (par exemple OVH, ou Gandi). Pour illustrer mes propos, je prendrai en exemple le nom de domaine nexxx.us que je loue chez OVH.

L’avantage de bind9 (ou named) c’est que le logiciel est administrable de la même manière sur presque toutes les distributions Linux (pas sur Ubuntu par exemple). Pour ma part j’utilise un Debian 5.0 accueillir mon serveur de nom.

Bon maintenant commençons. Loguez vous sur votre machine puis installons bind9 et vérifions le contenu du répertoire.

# aptitude install bind9 bind9utils
# ls -alh /etc/bind/
drwxr-sr-x 3 root bind 4.0K 2011-01-14 00:46 .
drwxr-xr-x 96 root root 4.0K 2011-01-13 10:40 ..
-rw-r--r-- 1 root root 237 2010-08-04 22:50 db.0
-rw-r--r-- 1 root root 271 2010-08-04 22:50 db.127
-rw-r--r-- 1 root root 237 2010-08-04 22:50 db.255
-rw-r--r-- 1 root root 353 2010-08-04 22:50 db.empty
-rw-r--r-- 1 root root 270 2010-08-04 22:50 db.local
-rw-r--r-- 1 root root 3.0K 2010-08-04 22:50 db.root
-rw-r--r-- 1 root bind 617 2011-01-11 22:16 named.conf
-rw-r--r-- 1 root bind 165 2010-08-04 22:50 named.conf.local
-rw-r--r-- 1 root bind 633 2010-12-20 13:18 named.conf.options
-rw-r----- 1 bind bind 77 2010-12-15 17:30 rndc.key
-rw-r--r-- 1 root root 1.3K 2010-08-04 22:50 zones.rfc1918

Tout d’abord quelques explications sur les différents fichiers. Les fichiers commençant par « db » sont des fichiers de bases de données pour les noms domaines gérés par bind. Les fichiers « db » avec des chiffres derrière sont les fichiers bases de données pour le reverse DNS avec les pointeurs inclus dedans. Nous ne nous occuperons pas du reverse DNS, car à moins que vous ne possédiez votre propre bloc d’adresses publiques vous ne pourrez pas gérer les pointeurs depuis votre serveur DNS. Nous allons donc maintenant créer notre propre fichier de zone :

# touch /etc/bind/db.nexxx.us
# vi /etc/bind/db.nexxx.us

$TTL    86400
@       IN      SOA ns0.nexxx.us. admin.nexxx.us(
2011011512      ; serial
28800           ; refresh, seconds
7200            ; retry, seconds
604800          ; expire, seconds
28800 )         ; minimum, seconds
 
; Bloc pour Name serveur
@       IN      NS      ns0.nexxx.us.
@       IN      NS      ns.kimsufi.com.
 
; bloc pour serveur MX
@       IN      MX      5       nh-ks01.nexxx.us.
 
; bloc generique
localhost       IN      A       127.0.0.1
localhost6      IN      AAAA    ::1
 
; Bloc pour machines
nexxx.us.       IN      A       94.23.28.6
ns0             IN      A       94.23.28.6
nh-ks01         IN      A       94.23.28.6
nh-ks02         IN      A       88.177.45.114
 
; Bloc Machine ipv6
ipv6.nexxx.usIN      AAAA    2001:41d0:2:1d06::1
 
; Bloc pour Alias environnement de production
mail            IN      CNAME   nh-ks01.nexxx.us.
www             IN      CNAME   nh-ks01.nexxx.us.

Passons à l’explication de ce fichier :

  • Le TTL (Time To Live) permet de définir le temps maximum de mise en cache de la résolution par les clients DNS. Typiquement ce paramètre est à 24H (86 400 secondes). Si ce paramètre est trop long cela diminue la vitesse de propagation, de vos modifications. en revanche s’il est trop court vous risquez de surcharger votre serveur de clients qui viennent vous réinterroger inutilement.
  • Le SOA (Start Of Authority) est en fait l’entête qui contient les informations générales sur le domaine. On y trouve :
    • le nom du  serveur primaire : ns0.nexxx.us.
    • l’adresse Email du gestionnaire avec un « . » au lieu de l’ « @ » : admin.nexxx.us.
    • le « serial »  qui identifie la version de votre fichier : 2011011512. Il ne faut pas oublier d’incrémenter ce paramètre lors de la mise à jour de vos entrées dns.
    • le « refresh » qui correspond au délai de mise à jour de vos slaves : 28800
    • le « retry »  qui correspond au délai à attendre pour un slave avant de relancer une mise à jour en échec : 7200
    • le « expire » qui définie le temps de validité d’une zone sur un slave s’il est dans l’incapacité de joindre le master : 604800
    • et enfin le « minimum » qui correspond au temps de mise en cache d’une réponse à un enregistrement non existant : 28800
  • Les enregistrements IN :
    • Les NS sont les serveurs DNS qui gèrent la zone. On déclare ici le master et les slaves
    • Les MX sont les serveurs de messageries. Ce champ est utilisé par les serveurs SMTP pour savoir où router les Email. Le MX a la particularité de posséder un champ « poids » qui défini la priorité entre les MX. Plus le chiffre est faible plus le serveur est prioritaire.
    • les A sont les champs d’hôte qui font la correspondance entre un nom et une IPv4.
    • les AAAA ont le même rôle que les A mais pour IPv6
    • les CMANE sont des alias de nom

Maintenant concentrons nous sur le fichier named.conf. Ce fichier contient le détail des zones administrées, avec les fichiers de bases de données associés. Les zones déclarées dans ce fichier ne concernent que la partie localhost pour le moment. Nous allons y ajouter la zone que nous venons de créer à la suite du fichier :

zone "nexxx.us" {
	type master; // Définie notre serveur en maitre sur la zone
	notify yes; // Active la notification de changement aux esclaves
	allow-transfer { 88.100.45.150; 213.186.33.199; }; // Liste des esclaves
	file "/etc/bind/db.nexxx.us"; // Emplacement du fichier de base de données
};

J’ai mis en commentaire dans le fichier ci dessus l’explication de chaque paramètre. J’y ai déclaré deux serveur slave (Le premier étant un autre de mes serveurs, le second étant un serveur mis à disposition par OVH pour cet usage).

Bon maintenant passons à la configuration général de bind. Ceci correspond au fichier named.conf.options.

# vi /etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
 
        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
 
        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.
 
        // forwarders {
        //      0.0.0.0;
        // };
 
        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { 2001:41d0:2:1d06::1; }; //adresse IPv6 d'écoute
        listen-on { 94.23.28.6; }; // adresse IPv4 d'écoute
        allow-recursion { 127.0.0.1; }; // Adresses des clients autorisés à résoudre autre chose que les zones gérés
};

Nous avons maintenant terminé la configuration de notre serveur, il nous faut relancer le service :
# /etc/init.d/bind9 restart
Stopping domain name service...: bind9 waiting for pid 2347 to die.
Starting domain name service...: bind9.

Vous pouvez voir dans le fichier de log la procédure de lancement du service, et vérifier le bon chargement de votre zone :
# cat /var/log/syslog|grep named
Jan 17 11:37:00 ks367743 named[13341]: zone 0.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone 127.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone 255.in-addr.arpa/IN: loaded serial 1
Jan 17 11:37:00 ks367743 named[13341]: zone localhost/IN: loaded serial 2
Jan 17 11:37:00 ks367743 named[13341]: zone nexxx.us/IN: loaded serial 2011011706
Jan 17 11:37:00 ks367743 named[13341]: running

Occupons-nous à présent de notre slave. ce dernier doit récupérer la zone de notre master de manière autonome et transparente. Pour cela on va éditer le fichier named.conf sur le slave pour lui rajouter notre zone.

zone "nexxx.us" {
        type slave;
        file "/etc/bind/db.nexxx.us";
        masters { 94.23.28.6; };
};

Une fois le fichier validé, relançons le service bind et vérifions que la zone ait bien été récupérée
# cat /var/log/syslog|grep named
Jan 17 11:48:27 nh-ks02 named[29378]: zone nexxx.us/IN: loaded serial 2011011706
Jan 17 11:48:27 nh-ks02 named[29378]: running
Jan 17 11:48:27 nh-ks02 named[29378]: zone nexxx.us/IN: sending notifies (serial 2011011706)

On peut constater que notre zone s’est correctement chargée au redémarrage.

Voilà notre domaine est créé.  Il faut dorénavant indiquer à notre registrar que nous prenons la responsabilité de la gestion du domaine. Dans notre exemple notre fournisseur est OVH.  Je vais donc vous fournir des captures d’écran qui vous indiqueront comment compléter au mieux les information fournies à notre prestataire.

Tout d’abord connectons-nous sur le manager et allons dans nos options de domaine :

Gestion des DNS OVH

Gestion des DNS OVH

Enfin modifions les propriétés pour que cela soit cohérent avec nos serveurs :

Nous y ajoutons nos serveurs DNS (le master en premier, les slaves ensuite), puis on valide les changements. Il faudra attendre au maximum 24 heures pour que cela se répercute sur les serveurs DNS du registrar (en général au bout d’une heure c’est bon).

Bon nous en avons presque terminé, maintenant il ne nous reste plus qu’a tester la bonne configuration du domaine. Et là, il existe un super outils founir par l’AFNIC : http://www.afnic.fr/outils/zonecheck . Il vous suffit d’entrer votre nom de domaine. Voici le résultat pour nexxx.us :

Afnic ZoneCheck

Un constate une erreur mineur, qui est lié au fait que le serveurOVH ne répond pas au ping (c’est pas notre problème :p)

Bon voilà nous avons maintenant l’entière responsabilité de notre domaine. A vous de jouer maintenant !

PS : En bonus, mon petit script qui permet de versioner et d’actualiser tout les N heures votre base DNS.

#!/bin/bash
#
# Script de mise a jour des DNS
#
#
SERIAL=`date +'%Y%m%d%H'`
BINDDIR=/etc/bind
DBN="db.nexxx.us"
DBF=$BINDDIR/$DBN
OLDF=$BINDDIR/old_$DBN
DOLD=15
LOGF=/tmp/dns_maint.log
TMPF=/tmp/$DBN.tmp
 
if [ -d "$OLDF" ];then
cp $DBF $OLDF/$DBN.$SERIAL
else
mkdir $OLDF
cp $DBF $OLDF/$DBN.$SERIAL
fi
 
# Purge des anciens fichier db
echo "Les fichier suivant vont être purgé :" > $LOG
find $OLDF/ -mtime +$DOLD -print >> $LOGF
find $OLDF/ -mtime +$DOLD -exec rm -f {} \;
echo "Fichier purgés !!!" >> $LOGF
echo "Mise à jour du serial DNS : " >> $LOG
OSERIAL=`cat $DBF|awk '/serial/ {print $1}'`
cat $DBF|sed 's/'$OSERIAL'/'$SERIAL'/g' > $TMPF
cp $TMPF $DBF
echo "Fichier DNS mis à jour, nouveau Serial : "$SERIAL >> $LOG
echo "Rechargement du cache BIND">> $LOGF
/etc/init.d/bind9 reload >> $LOGF
rm $TMPF
echo "Fin du programme !">> $LOGF

(2 commentaires)

  1. Bonjour, je voulais savoir quel était l’intérêt de gérer nous même le serveur dns de notre domaine? Ne vaut-il pas mieux laisser ça au registrar?

  2. Salut,

    J’avoue que d’utilisé le registrar ça a un coté pratique. mais depuis je viens d’implémenter la gestion du protocole Jabber par le DNS qui n’aurait pas été faisable via l’IHM d’OVH.

Laisser un commentaire

Your email address will not be published.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.