Installer et configurer un serveur DNS

Le deuxième article de cette nouvelle rubrique traite logiquement de la mise en place d’un serveur DNS. À moins que vous n’ayez recours à l’outil de gestion de vos DNS proposé par votre registrar et qu’il ne vous bride pas, vous devrez passer par l’étape du serveur DNS, d’autant qu’il nous permettra par la suite de faire bien d’autres choses que simplement faire pointer un domaine sur une IP…

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.

Important : _exemple.fr_

Pare-feu

Tout d’abord, reprenons le script de pare-feu que nous avons configuré précédemment.

nano /scripts/firewall

Entre les lignes :

##### Configuration personnalisée #####

Et :

##### Fin : Configuration personnalisée #####

Rajoutez les lignes suivantes :

${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

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

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 : 2012020514 et 2012020527.

Important : ZoneCheck

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 <localhost>.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 “minerva”, sur le domaine ingnu.fr. La commande qui s’applique à mon cas devient donc :

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

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

Vous disposez désormais de l’une des pièces maîtresses de votre propre serveur. La configuration de base que nous avons mis en place aujourd’hui va être complétée et sécurisée au fil des articles à venir, pour qu’au final, vous disposiez d’une solution complète vous permettant de vous affranchir des services offerts par Google, Twitter, facebook et bien d’autres. Le serveur que nous allons monter avec ces articles va vous permettre de reprendre le contrôle de vos données. Alors à bientôt pour le prochain article, qui traitera de la deuxième pierre angulaire de votre Cloud personnel et Libre : le serveur mail.