logo-netfolio

Installation du service DNS Bind9

Ce tutoriel détaille la mise en place du service DNS « Bind9 », je mettrai également en place un service secondaire.

1. Pré-requis :

Lors de ce tutoriel deux notions seront abordées, à savoir un service DNS Principal ou je vais détailler la mise en place et la configuration du service « Bind9 ».

Ensuite je vais mettre en place un service DNS secondaire servant de FailOver, c’est à dire que ce dernier prendra le relai en cas de problème sur le service DNS principal. J’ai déjà abordé cette notion lors du projet Nagios, j’y reviendrai quand même afin d’avoir un tutoriel aussi complet que possible.

Pour résumer, deux machines sous Debian seront créées :

Certaines autres informations doivent êtres précisées sur le contexte dans lequel ce tutoriel est réalisé, trois réseaux sont interconnectés via une machine Debian transformée en routeur cependant ces trois serveurs sont isolés d’internet.

Donc les serveurs DNS ne pourront contacter les serveurs DNS racines, c’est pourquoi j’ai modifié les fichiers « /etc/bind/db.root » et « /etc/bind/named.conf.default-zones » pour redéfinir la racine comme étant le serveur DNS principal, cela évite d’inonder les logs de messages d’erreurs m’informant que les serveurs racines ne sont pas joignables.

Cependant en situation réel faire cela empêche les hôtes dépendant du service DNS interne de résoudre les noms qui ne sont pas répertoriés sur celui-ci.

En sachant cela, seul les noms des machines sur les trois réseaux seront répertoriées et accessibles.

2. Serveur DNS Principal :

2.1. Fichiers de configuration :

Avant de commencer, il faut savoir qu’on distingue deux méthodes de résolution de nom, la méthode de résolution direct permettant l’obtention d’adresse IP à partir d’un nom pleinement qualifié(FQDN) et la méthode de résolution inverse permettant de faire le contraire. Dans le cas de ce tutoriel une zone inverse sera donc créée correspondant à la zone « folio.fr ».

Pour installer Bind9 sous Debian il suffit d’installer le paquet du même nom à l’aide d’un gestionnaire de paquet quelconque.

Pour commencer on va ajouter une directive permettant d’autoriser le serveur DNS principal à interroger d’autre serveur pour résoudre un nom.

Il faut donc éditer le fichier de configuration « /etc/bind/named.conf.options » afin d’ajouter la ligne ci-dessous(en rouge) :
Configuration-Bind9-NamedOptions
Ensuite il faut déclarer les zones(domaines) dans le fichier « /etc/bind/named.conf.local » :
Configuration-Bind9-NamedLocal-Reverse

il faut savoir qu’une zone inverse(en jaune) permet une résolution dite inverse afin d’obtenir un nom à partir d’une adresse IP.

Donc pour déclarer un domaine il suffit d’indiquer son nom, ici « folio.fr » pour la résolution direct et « 168.192.in-addr.arpa » pour la résolution inverse. Ensuite il faut préciser le statut de ce serveur, master car il fait autorité sur le domaine en question. C’est à dire que les fichiers RRs(voir ci-dessous) pour cette zone se trouve sur ce serveur, à noté que plusieurs serveurs peuvent faire autorités pour le même domaine.

« file » permet d’indiquer le chemin vers les fichiers RRs(Resource Records) ou seront définit les associations, cette étape est abordée lors de l’étape suivante.

2.2. Fichiers « Resource Records » :

Deux fichiers sont à créer(un par zone) dans lesquels il faut déclarer les noms associés à leur adresses IP. Il est important de savoir que plusieurs autres choses tels que des adresses mails, des valeurs EUI48 ou encore des clés publiques DNS peuvent êtres définis dans ces fichiers, mais cela sort du cadre de ce tutoriel.

Donc le répertoire ou sont situés ces fichiers est par défaut « /var/cache/bind/ », le ficher « managed-keys.bind » est utilisé dans le cas de DNSSEC c’est à dire la version sécurisé du service DNS, je n’aborderai pas cette notion lors de ce tutoriel.

Le fichier « db.folio » correspond à la zone en résolution direct et « rev.folio » à la zone en résolution inverse :
Commande-Ls-RRs
Ci-dessous se trouve le contenu du fichier « db.folio » :
Configuration-Fichier-RRs

Plusieurs choses sont à préciser, pour commencer les variables « $TTL » et « $ORIGIN » permettent d’indiquer respectivement le délai d’expiration des données mises en cache, puis le nom de domaine dit pleinement qualifié(FQDN) utilisé dans la suite du fichier.

Le protocole DNS est hiérarchique, en effet aucun serveur DNS ne contient tous les noms de domaine, ils sont repartit par niveau, on a en premier lieu la racine, indiquée par un point, ensuite le « tld »(top level domain), « .fr » dans le cas présent. Plus il y a de niveau plus le FQDN sera long, pour « folio.fr. » on a donc deux niveaux sans compter la racine.

C’est donc pour cela qu’il est impératif qu’un FQDN se termine par un point, sans cela un nom de domaine ne peut être un FQDN. Le symbole « @ » et la tabulation représentent la valeur définit dans la variable « $ORIGIN ».

Un enregistrement « SOA »(en rouge), pour « Start Of Authorority » définit les paramètres globaux du domaine. Donc on indique la machine faisant autorité sur la zone(servbind) suivit de l’adresse mail de la personne responsable(master), puis vient une série de valeur correspondant dans l’ordre au :

Ensuite les enregistrements « Name Server »(NS) définissent le ou les serveurs DNS du domaine, il peut y en avoir plusieurs en cas de DNS secondaire par exemple(en vert).

Les enregistrements « A »(Address Record) permettent l'attribution d’un nom à une adresse IPv4. Il n’y a pas besoin d’indiquer ces noms sous leurs formes FQDN, d’où l’absence de point. Pour IPv6 l’enregistrement à utiliser est « AAAA ».

Pour finir, le dernier enregistrement « CNAME »(Canonical Name), permet l’attribution de plusieurs noms pour une seule adresse IP, ceci est notamment utilisé pour les serveurs web hébergeant plusieurs sites web.

C’est maintenant au tour du RRs « rev.folio » :
Configuration-Fichier-RRs-Reverse

Lors des enregistrement de la zone inverse, on fait correspondre une adresse IP a un FQDN, l’obligation d’indiquer le FQDN à gauche viens du fait que la variable « $ORIGIN » contient le domaine « 168.192.in-addr.arpa ». Par exemple(en rouge) dans le cas on l’on indiquerai juste « 9.11 » la valeur serait transformée en « 9.11.168.192.in-addr.arpa. ».

L’enregistrement « PTR »(Pointer Record) équivaut aux enregistrements « A » de la zone direct.

Maintenant il faut redémarrer le service(en rouge) et afficher une partie(en bleu) des logs afin de prendre en compte les configurations effectuées puis de vérifier s’il y a des erreurs :
Configuration-Bind9-Restart

Comme on peut le voir les deux zones qui nous intéresse on bien été chargées.

C’est tout pour la mise en place d’un seul serveur DNS faisant autorité, la prochaine partie détaille la mise en place d’un service secondaire pour les zones précédemment définies.

3. Serveur DNS Secondaire :

Un serveur DNS secondaire permet d’augmenter la résilience du service DNS via la redondance, en effet en cas de défaillance du service principal, le service secondaire prendra le relai.

Pour cela il suffit d’installer le service « bind9 » sur le serveur DNS secondaire de la même manière que ce qui a été fait sur le serveur DNS principal.

3.1. Fichiers de configuration :

Uniquement les fichiers de configuration du service seront à configurer, cela est du au fait que les fichiers « Resource Records », « db.folio » et « rev.folio » seront téléchargés depuis le serveur DNS principal.

A l’instar de ce qui a été fait sur le serveur DNS principal, Il faut éditer le fichier de configuration « /etc/bind/named.conf.options » afin d’ajouter la ligne ci-dessous(en rouge) :
Configuration-Bind9-Secondaire-NamedOptions
Ensuite il faut également déclarer les zones(domaines) dans le fichier « /etc/bind/named.conf.local » :
Configuration-Bind9-Secondaire-NamedLocal

On remarque quelques différences avec ce qui a été fait sur le serveur principal, à savoir le type qui est cette fois définit en tant que « slave » ce qui signifie que les « Resource Records » seront récupérés sur le serveur DNS principal.

Ensuite on indique l’adresse IP du serveur DNS principal via la directive « masters ».

C’est tout ce qu’il y a à faire pour le serveur DNS secondaire, il ne manque plus qu’à redémarrer le service et de vérifier le transfert des RRs.

Rien de mystérieux pour le redémarrage, il suffit d’utiliser les même commandes que précédemment :
Configuration-Bind9-Secondaire-Restart

Une fois de plus le service n’a pas rencontré de problème.

Pour vérifier le transfert des RRs, il faut chercher dans les logs des « daemons » du serveur DNS secondaire via la commande « tail -n 100 /var/log/daemon.log | less » par exemple :
Test-DNS-Transfer-Zone-Logs

Les lignes ci-dessus indiquent la réussite des transferts, en premier trouve la zone « 168.192.in-addr.arpa »(en rouge) et ensuite la zone « folio.fr »(en vert).

4. Client :

Maintenant que les serveurs DNS sont prêts, il faut configurer les clients, en effet ceux-ci utilisent un « resolver » pour interroger les serveurs DNS.

La configuration du « resolver » sous Debian se fait via le fichier « /etc/resolv.conf » :
Client-DNS-Resolver

On indique le domaine puis les serveurs à joindre.

Pour Windows, il faut aller dans « Panneau de configuration\Réseau et Internet\Connexions réseau » puis « Clic-droit>Propriétés » sur la carte réseau. Ensuite il faut sélectionner « Protocole Internet version 4 » et « Propriétés » :
Client-DNS-Resolver-Windows

Enfin dans les champs adéquat on indique les adresses IP des serveurs DNS.

5. Tests :

Pour tester le bon fonctionnement des serveurs DNS deux commandes seront utilisées à savoir « nslookup » et « dig », la seconde est préférable car elle donne plus d’informations cependant j’utiliserai les deux.

On commence par tester la zone sur le serveur DNS principal en résolution direct :
Test-DNS-Nslookup

Une fois la commande « nslookup » entrée, l’invite de commande change et il suffit de taper le FQDN à résoudre.

Ci-contre on voit bien que la résolution c’est bien effectuée avec succès(en vert) et ce, par le serveur DNS principal(en rouge).

Toujours sur le serveur principal on test la zone en résolution inverse, pour cela j’utilise la commande « dig -x 192.168.11.9 » :
Test-DNS-Dig

Dans le champs réponse(en violet) on voit la réponse obtenue cela nous indique donc que l’adresse 192.168.11.9 correspond au FQDN « mysqlslave.folio.fr. ». Le serveur DNS qui a répondu est indiqué en bleu.

Pour tester le fonctionnement du serveur secondaire il suffit d’arrêter le service DNS sur le serveur principal et d’effectuer les mêmes tests que précédemment afin de voir si le serveur secondaire prend bien le relai.

Pour arrêter le service DNS sur le serveur principal il suffit d’utiliser la commande « service bind9 stop », ensuite on relance « nslookup » sur un client afin de tester la zone direct :
Test-DNS-Nslookup-Secondaire

Comme on peut le voir le serveur secondaire a bien pris le relai(en rouge).

Ensuite on utilise de nouveau la commande « dig -x 192.168.11.9 » :
Test-DNS-Dig-Secondaire

Le serveur ayant répondu est bien le serveur DNS secondaire(en bleu).