Vous êtes sur la page 1sur 13

Préparation du Serveur DNS Maître pour DDNS

Avant de configurer le serveur DHCP, il va d’abord être nécessaire de préparer le serveur


DNS Maître pour permettre au serveur DHCP de mettre à jour dynamiquement les zones
domain.lan et 0.168.192.in-addr.arpa. Cette manipulation n’est bien sûr pas nécessaire sur le
serveur DNS Esclave puisque le serveur DNS Maître lui transférera ses zones.

Génération de la clé pour sécuriser les échanges DNS/DHCP

Pour permettre la communication entre les serveurs DNS et DHCP, une clé devra être utilisée.
La clé sera générée sur le serveur DNS à l’aide de la commande suivante :

root@ns1:~# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER


DDNS_UPDATE

La commande précédente est bien entendu à adapter selon vos besoins. Elle va générer deux
fichiers :

La clé qui sera utilisée par chacun des deux serveurs sera située dans le fichier dont
l’extension est « .private ». Dans le cas présenté ici, le fichier à ouvrir sera le fichier nommé «
Kddns_update.+157+57083.private ».

Vous devrez alors copier le contenu situé à la ligne commençant par « Key : » comme montré
ci-dessous :

Il va maintenant être nécessaire de créer un nouveau fichier nommé ddns.key qui sera situé
dans le répertoire /etc/bind et qui va contenir la clé récupérée dans le fichier précédent.

Voici le contenu à ajouter dans le fichier /etc/bind/ddns.key :


Ici, « DDNS_UPDATE » correspond au nom donné à la clé. C’est ce nom qui sera réutilisé
dans les fichiers de configuration de Bind et de DHCP pour appeler la clé. Le paramètre secret
correspond à la clé récupérée dans le fichier Kddns_update.+157+57083.private précédent.
Cette valeur est donc à adapter en fonction de votre configuration.

Une fois que ce fichier est sauvegardé, il sera nécessaire de modifier les droits appliqués à ce
fichier.

root@ns1:~# chown root:bind /etc/bind/ddns.key


root@ns1:~# chmod 640 /etc/bind/ddns.key

Maintenant que la clé utilisée pour l’échange entre le serveur DNS et le serveur DHCP a été
créée et configurée, il va être nécessaire de modifier la configuration de Bind pour l’utilisation
de la clé générée…

Modification de la configuration de Bind

Pour permettre le fonctionnement de DDNS, la configuration de Bind définie précédemment


dans mes articles va devoir être adaptée. Vous pourrez trouver les liens de mes précédents
articles en introduction.

Il va d’abord être nécessaire de modifier le fichier /etc/bind/named.conf.local dans lequel les


zones domain.lan et 0.168.192.in-addr.arpa sont déjà définies.

Voici le nouveau contenu du fichier named.conf.local :


Les modifications apportées au fichier sont les suivantes :

 Il est d’abord nécessaire d’intégrer le fichier ddns.key créé précédemment à la


configuration de Bind, la clé pourra ainsi être réutilisée à partir de son nom.
 Pour chaque zone, on modifie la directive allow-update afin d’autoriser les mises à
jour de la zone à partir d’un client possédant la clé passée en paramètre.
 Enfin, il faut également modifier l’emplacement des fichiers de zone en utilisant le
répertoire /var/cache/bind qui est accessible en écriture par l’utilisateur bind (ce qui
n’est pas le cas pour le répertoire /etc/bind).

Une fois que le fichier named.conf.local a été modifié, il va être nécessaire de créer un lien
symbolique des fichiers de zone vers le répertoire /var/cache/bind…

root@ns1:~# cd /var/cache/bind
root@ns1:/var/cache/bind# ln -s /etc/bind/db.domain.lan .
root@ns1:/var/cache/bind# ln -s /etc/bind/db.0.168.192.in-addr.arpa .

Une fois que les liens symboliques ont été créés, le serveur DNS sera configuré pour DDNS.
Il reste encore à installer le service DHCP et à le configurer…
Déploiement du Service DHCP

Maintenant que le serveur DNS ns1.domain.lan est configuré pour DDNS, il va tout d'abord
être nécessaire d’installer le service DHCP à l'aide de la commande suivante :

root@dhcp:~# aptitude install isc-dhcp-server

Comme précisé dans la partie précédente de cet article, le serveur DHCP va être autorisé à
modifier les zones gérées par le serveur DNS ns1.domain.lan à l’aide d’une clé permettant la
sécurisation des échanges entre les deux serveurs. Le serveur DHCP va donc devoir posséder
une copie du fichier ddns.key créé précédemment dans le répertoire /etc/bind/ du serveur
DNS.

Le fichier ddns.key devra être copié dans le répertoire /etc/dhcp comme montré ci-dessous. Je
vous conseille au préalable d'ajouter le serveur DHCP dans les zones de résolution directe et
inverse gérées par le serveur DNS Maître.

Comme sur le serveur DNS, il sera également nécessaire de modifier les droits de ce fichier…

root@dhcp:~# chown root:root /etc/dhcp/ddns.key


root@dhcp:~# chmod 640 /etc/dhcp/ddns.key

Nous allons maintenant définir les éléments de configuration du service DHCP. Pour cela, il
va être nécessaire d’éditer le fichier /etc/dhcp/dhcpd.conf…

Voici l’intégralité du contenu du fichier dhcpd.conf :


Les directives utilisées dans ce fichier sont les suivantes :

 authoritative permet de préciser au serveur DHCP qu'il est le serveur DHCP prioritaire
sur le réseau local.
 ddns-updates permet ici d’autoriser les mises à jour des zones DNS associées en
fonction des adresses IPv4 distribuées.
 ddns-update-style permet de définir quel type de mise à jour sera utilisé pour DDNS.
Ici, le paramètre interim précise qu'il s’agit d’une mise à jour vers un serveur DNS
local.
 ignore client-updates permet d’empêcher les clients de s’enregistrer eux-mêmes auprès
du serveur DNS.
 update-static-leases permet de préciser si le serveur DHCP est autorisé ou non à
modifier des enregistrements DNS statiques définis dans les fichiers de zone.
 log-facility permet de préciser que le niveau de log utilisé dans le fichier
/var/log/syslog. Ici, il sera au niveau debug (valeur 7).
Dans le fichier dhcpd.conf, on voit également que le fichier /etc/dhcp/ddns.key est intégré à la
configuration du service DHCP à l’aide de la directive include.

La clé précisée dans ce fichier est ensuite utilisée lors de la déclaration des zones DNS
utilisées pour DDNS (paramètre key). Le paramètre « primary » permet de préciser l’adresse
IPv4 (ou le nom FQDN) du serveur DNS à contacter pour insérer, modifier ou supprimer un
enregistrement de cette zone.

L’étendue DHCP est alors déclarée. Ici l’étendue DHCP va de 192.168.0.200/24 à


192.168.0.210/24 Les options ddns-domainname et ddns-rev-domainname permettent de
préciser les zones DNS directe et inverse utilisées pour déclarer les noms FQDN des clients.

Lorsque la configuration du fichier dhcpd.conf a été enregistré, il ne reste plus qu'à


redémarrer les services isc-dhcp-server (sur le serveur DHCP) et bind9 (sur le serveur DNS)
afin d’appliquer les modifications…

root@ns1:~# service bind9 restart


root@dhcp:~# service isc-dhcp-server restart

Validation du fonctionnement des services

Les services DNS et DHCP étant désormais configurés, il ne reste plus qu'à tester le
fonctionnement des services DHCP et DDNS.

Pour cela, il va être nécessaire d’ouvrir le fichier de logs /var/log/syslog à l’aide de la


commande tail sur le serveur DHCP. Cela permettra de voir les actions effectuées par le
DHCP :

Sur le réseau local, un client Windows 10 sans carte réseau active sera démarré pour effectuer
les tests…
Lors de l’activation de l’une des cartes réseau du client, le serveur DHCP devrait
automatiquement distribuer un lot de paramètres réseau au client…
Dans les logs, on pourra constater les échanges entre le serveur DHCP et le client avec les
requêtes DHCP DISCOVER, OFFER, REQUEST et ACK. On pourra également constater
l’enregistrement du client au sein des zones DNS avec les lignes « Added new forward map »
et « Added reverse map » :
Sur le client, on pourra également constater la réception des paramètres réseaux :
Enfin, il ne reste plus qu'à vérifier la résolution DNS du client. Pour cela, on utilise la
commande dig comme montré ci-dessous :
La résolution DNS directe du client semble donc fonctionner, mais il est également nécessaire
de valider la résolution inverse. Pour cela, il faut utiliser la commande dig en précisant
l’option -x comme montré ci-dessous :
Il pourra également être intéressant de vérifier la résolution depuis le serveur DNS Esclave en
dirigeant la requête vers le serveur ns2.domain.lan.

Les enregistrements DNS ajoutés dynamiquement devraient être automatiquement répliqués


sur le serveur DNS Esclave comme s’il s’agissait d’enregistrements ajoutés manuellement au
sein d’une zone. Il est néanmoins possible que ces enregistrements ne soient pas
immédiatement renseignés sur ns2.domain.lan en fonction du délai de rafraîchissement choisi.

Pour diriger la requête DNS vers le serveur ns2.domain.lan, il faudra utiliser la commande
suivante :
s