Installer et configurer un serveur DNS

Dans ce tutoriel on va voir comment créer son propre serveur DNS. Votre registrar propose certainement déjà un outil permettant de le gérer, mais c’est toujours intéressant de savoir faire soi-même avant de déléguer non ? La curiosité !

ethernet

Nous utiliserons le serveur bind. Nous allons tout d’abord l’installer sur le serveur principal en tant que maître. Si vous disposez d’un second serveur, vous pourrez le configurer en tant qu’esclave pour assurer la continuité du service.

Pour la suite de notre article (et pour tous les articles à venir), nous considérerons que vous êtes l’heureux possesseur du domaine exemple.fr, et que vous disposez de deux serveurs ayant les adresses IP 1.1.1.1 et 2.2.2.2. Si vous n’avez qu’un seul serveur à disposition, vous n’aurez besoin de faire que de petits ajustements qui n’empêcheront pas le système de fonctionner correctement. Vous pouvez également installer temporairement bind sur votre propre machine pour passer les tests de validation.

Pare-feu

Dans cet exemple, on va modifier le script pour iptables. Je suis plus un adepte de Shorewall, mais vu que personne ne l’utilise, ça n’aurait pas d’intérêt.

IPT=/sbin/iptables
${IPT} -A SERVICES -p tcp --dport 53 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Nous ouvrons donc le port 53 en TCP et en UDP. Normalement, seul le protocole UDP est utilisé pour les requêtes, mais le protocole TCP est utilisé également pour les transferts de zones dont nous aurons besoin plus tard. Il est donc important d’ouvrir les connexions aux deux types de protocoles, à moins que vous ne configuriez pas un serveur esclave. Nous pourrions également spécifier directement l’adresse du serveur esclave afin d’éviter toute demande de transfert directement depuis iptables :

${IPT} -A SERVICES -p tcp --dport 53 -s 2.2.2.2 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Serveur maître

Pour installer bind, rien de plus simple : apt-get install bind9 dnsutils
Le paquet dnsutils contient notamment les outils nslookup et dig, qui nous serviront par la suite à tester notre installation.
Rendez-vous dans le répertoire de configuration de bind :

cd /etc/bind
/etc/init.d/bind9 stop

Réflexe à acquérir : toujours stopper un processus en cours d’exécution avant d’en modifier la configuration. Cela évite quelques surprises du genre configuration qui revient à son état précédent une fois le service relancé.

On créé le fichier le définition de notre domaine :

nano db.exemple.fr
$TTL 86400
@ IN SOA ns.exemple.fr. postmaster.exemple.fr. (
2012020501
2D ; Refresh
15M ; Retry
3W ; Expire
86400 ) ; Negative Cache TTL

IN NS ns.exemple.fr.
IN NS ns2.exemple.fr.

IN A 1.1.1.1

ns IN A 1.1.1.1
ns2 IN A 2.2.2.2

Les domaines se terminent par un « . » !

Quelques explications s’imposent. Dans la ligne relative au SOA, on déclare le serveur DNS autoritaire pour la zone (ns.exemple.fr) et l’adresse email du responsable (postmaster.exemple.fr, le « @ » de l’adresse étant remplacé par un « . »).

Ensuite, on attribue un numéro de série au fichier ; ce numéro ne s’invente pas : il s’agit de la date (au format YYYYMMDD) suivi d’un nombre compris entre 00 et 99. Pour plus de clarté, on va appeler ce nombre la « clé ». Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, « j’attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr« ), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.

Par exemple, vous faites 4 modifications sur le fichier db.exemple.fr, et 7 sur le fichier db.exemple2.fr, en date d’aujourd’hui. Vous pouvez attribuer les numéros de série suivants à vos fichiers : 2016101301 et 2016101330. N’oubliez jamais de modifier le numéro de série à chaque modification du fichier !
Si vous ne disposez que d’un seul serveur, vous pouvez omettre les lignes relatives au deuxième serveur DNS (ns2.exemple.fr et son adresse associée 2.2.2.2). Cependant, vous ne passerez pas les tests de validation si votre registrar a recours au Zonemaster (anciennement ZoneCheck) de l’AFNIC, qui exige que vous ayez deux serveurs DNS configurés. Vous devriez installer temporairement un serveur bind sur votre propre machine.

Les valeurs suivantes (refresh, retry, etc.) devraient convenir à la majorité des situations.
Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : ns.exemple.fr. et ns2.exemple.fr.
Ensuite, nous indiquons que le serveur principal a pour adresse IP 1.1.1.1, puis nous associons les adresses 1.1.1.1 et 2.2.2.2 aux deux serveurs de noms. Une fois que vous avez adapté cet exemple à votre propre domaine, vous pouvez enregistrer et fermer.

Théoriquement, dans une installation de base de bind sur une Debian stable, le fichier named.conf contient la ligne suivante :

include "/etc/bind/named.conf.local";
#Si ce n’est pas le cas, rajoutez-là :
echo "include \"/etc/bind/named.conf.local\";" >> named.conf
#Et modifiez le fichier named.conf.local :
nano named.conf.local

Ce fichier va contenir les directives de configuration pour un domaine particulier, en l’occurrence, exemple.fr (et/ou exemple2.fr). C’est une bonne pratique de configuration à laquelle passe la majorité des applications, cela permet de clarifier les choses, et de s’y retrouver facilement.

Mettez donc le contenu suivant dans ce fichier :

zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
};

On défini notre instance de bind comme étant maître pour ce domaine, et on lui indique le fichier de configuration correspondant. Enregistrez et fermez ce fichier une fois modifié. Redémarrez ensuite bind, pour procéder à quelques tests :

/etc/init.d/bind9 restart
nslookup exemple.fr
Vous devriez obtenir la sortie suivante :
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

Vous noterez qu’à cause de la propagation des DNS, votre domaine n’est peut être pas encore disponible depuis l’extérieur. N’hésitez pas à tester (en utilisant la même commande) régulièrement depuis une machine qui n’héberge pas le serveur bind.

Si la commande précédente vous retourne une sortie similaire, c’est que votre domaine est correctement configuré (du point de vue de bind en tout cas). En l’état actuel des choses, bind devrait donc être en mesure de répondre à des requêtes portant sur votre domaine, bien qu’encore aucun domaine « utile » ne soit créé.

Serveur esclave

Pour faire fonctionner deux instances de bind sur le modèle de maître/esclave, on commence par compléter un peu la configuration du serveur maître. On reste donc sur la même machine, pour créer une clé de transfert :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST .exemple.fr.

dnssec-keygen est un outil livré avec bind. Grâce à la commande suivante, on génère une clé en utilisant l’algorithme HMAC-MD5, d’une longueur de 512 bits, pour un hôte particulier (-n HOST), en l’occurrence, celui indiqué à la fin. Remplacez par le nom d’hôte du serveur. Par exemple, j’ai appelé mon serveur « foo », sur le domaine exemplebis.fr. La commande qui s’applique à mon cas devient donc :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST foo.exemplebis.fr.

Notez toujours le point à la fin du domaine. On génère une clé pour un hôte donné, mais dnssec-keygen permet bien d’autres choses que nous n’utiliserons pas ici. Notamment, vous pouvez choisir un algorithme différent, ou créer une clé pour toute une zone. Pour l’heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier db.exemple.fr) de notre serveur maître vers le serveur esclave que nous configurerons plus tard. Cette commande est donc suffisante pour le moment.

A l’issue de l’exécution de cette commande (qui peut durer une vingtaine de secondes), deux nouveaux fichiers ont été créés. Ils commencent par la lettre K majuscule, et portent respectivement l’extension .key et .private. Le premier fichier contient une ligne qu’il est possible de rajouter dans un fichier de zone, tandis que le second contient quelques détails sur la création de la clé. Nous n’utiliserons dans notre cas précis aucun des deux dans son état actuel. Cependant, il peut être utile de les conserver pour un usage ultérieur.

La seule chose qui nous intéresse est la clé en elle-même qui figure dans les deux fichiers. Utilisez la commande cat sur le fichier .private, et copiez la clé qui apparaîtra. Créez ensuite le fichier transfer.conf :

nano transfer.conf
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};

server 2.2.2.2 {
keys {
TRANSFER;
};
};

Dans ce fichier, nous ajoutons une clé au « trousseau » de bind, qui ne sera destinée qu’au transfert des zones entre le maître et l’esclave. Si un cas se présente où nous devrons diffuser d’autres clés, nous en générerons de nouvelles, pour éviter toute interférence.

Ensuite, nous affectons cette clé au serveur esclave, 2.2.2.2. Incluez ce fichier à votre configuration, puis modifiez le fichier named.conf.local :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
nano named.conf.local
zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
allow-transfer { 2.2.2.2; };
};

Nous avons rajouté la ligne allow-transfer { 2.2.2.2; }; qui nous permet d’éviter que n’importe qui puisse transférer nos zones sur son serveur. Redémarrez bind :

/etc/init.d/bind9 restart

Désormais, lorsque le serveur maître redémarrera, il notifiera automatiquement le(s) serveur(s) esclave(s) de tout changement, et initiera le transfert des zones de manière sécurisée.

Passons maintenant à la configuration du serveur esclave à proprement parlé. Sur la machine qui hébergera ce serveur, installez bind :

apt-get install bind9 dnsutils

Nous avons créé le fichier transfer.conf sur le serveur maître. Le même fichier doit être créé sur la machine esclave, avec une petite nuance.

cd /etc/bind
/etc/init.d/bind9/stop
nano transfer.conf
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};

server 1.1.1.1 {
keys {
TRANSFER;
};
};

Vous noterez qu’il s’agit exactement du même fichier, y compris la même clé, mais que l’adresse IP de la clause server change. Dans la configuration du serveur esclave, c’est l’adresse IP du serveur maître qu’il faut indiquer. Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier à la configuration de bind :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf

Modifions ensuite le fichier named.conf.local pour y ajouter la configuration de votre (vos) domaine(s) :

zone "exemple.fr" {
type slave;
file "/var/cache/bind/db.exemple.fr";
masters { 1.1.1.1; };
allow-notify { 1.1.1.1; };
};

Nous indiquons ici que le fichier de zone db.exemple.fr, une fois transféré, sera stocké dans le dossier /var/cache/bind, qui devrait déjà être créé. Si ce n’est pas le cas, il faut le créer, et donc tous les cas, lui attribuer les bons droits :

mkdir -p /var/cache/bind
chown -R bind:bind /var/cache/bind
chmod -r 644 /var/cache/bind

Il suffit maintenant de redémarrer bind pour que les modifications soient prises en compte.

/etc/init.d/bind9 restart

Consultez immédiatement les journaux utilisés par bind :

tail -100 /var/log/syslog

Il se peut que vous y trouviez une erreur à propos de l’heure qui n’est pas synchronisée. Installez sur les deux serveurs le paquet ntpdate, puis synchronisez les horloges avant de redémarrer bind :

apt-get install ntpdate
ntpdate 0.fr.pool.ntp.org
/etc/init.d/bind9 restart

Testez maintenant votre serveur :

nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> exemple.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

That’s it !
<3

Recherches utilisées pour trouver cet article :créer son propre serveur dns
metrogeek

Comments 2

    1. C’est vrai que je devrais ajouter tout ça, mais pour l’instant, ce blog n’a aucune vocation pro 😉

      PS : j’ai supprimé le lien short, la destination était en 404

Laisser un commentaire