Introduction

Le DNS, ou le système de nom de domaine, est souvent un composant difficile à obtenir correctement lorsqu’on apprend à configurer des sites Web et des serveurs. Alors que la plupart des gens choisiront probablement d’utiliser les serveurs DNS fournis par leur société d’hébergement ou leur registraire de domaine, il y a certains avantages à créer vos propres serveurs DNS.

Dans ce guide, nous discuterons de la façon d’installer et de configurer le serveur DNS Bind9 comme serveurs DNS faisant autorité uniquement sur des machines Ubuntu 14.04. Nous allons mettre en place ces deux serveurs Bind pour notre domaine dans une configuration primaire-secondaire.

Prérequis et objectifs

Pour compléter ce guide, vous devrez d’abord vous familiariser avec certaines terminologies DNS courantes. Consultez ce guide pour connaître les concepts que nous allons mettre en œuvre dans ce guide.

Vous aurez également besoin d’au moins deux serveurs. L’un sera pour le serveur DNS « primaire » d’où proviendront les fichiers de zone pour notre domaine et l’autre sera le serveur « secondaire » qui recevra les données de zone par transferts et sera disponible en cas de panne de l’autre serveur. Cela évite le péril d’avoir un seul point de défaillance pour vos serveurs DNS.

Contrairement aux serveurs DNS de mise en cache ou de transfert ou à un serveur DNS polyvalent, les serveurs faisant autorité uniquement répondent aux requêtes itératives pour les zones pour lesquelles ils font autorité. Cela signifie que si le serveur ne connaît pas la réponse, il se contentera de dire au client (généralement un type de serveur DNS de résolution) qu’il ne connaît pas la réponse et de donner une référence à un serveur qui pourrait en savoir plus.

Les serveurs DNS faisant autorité uniquement sont souvent une bonne configuration pour des performances élevées car ils n’ont pas la surcharge de résolution des requêtes récursives des clients. Ils ne se soucient que des zones qu’ils sont conçus pour servir.

Pour les besoins de ce guide, nous ferons en fait référence à trois serveurs. Les deux serveurs de noms mentionnés ci-dessus, plus un serveur web que nous voulons configurer comme hôte dans notre zone.

Nous utiliserons le domaine fictif example.com pour ce guide. Vous devriez le remplacer par le domaine que vous configurez. Voici les détails des machines que nous allons configurer:

But	DNS FQDN	Adresse IP
Serveur de nom primaire	ns1.exemple.com.	192.0.2.1
Serveur de nom secondaire	ns2.exemple.com.	192.0.2.2
Serveur Web	www.example.com.	192.0.2.3

Après avoir terminé ce guide, vous devriez avoir deux serveurs de noms faisant autorité uniquement configurés pour vos zones de domaine. Les noms de la colonne centrale du tableau ci-dessus pourront être utilisés pour atteindre vos différents hôtes. En utilisant cette configuration, un serveur DNS récursif sera en mesure de renvoyer des données sur le domaine aux clients.

Configuration du nom d’hôte sur les serveurs de noms

Avant de passer à la configuration de nos serveurs de noms, nous devons nous assurer que notre nom d’hôte est configuré correctement sur notre serveur DNS primaire et secondaire.

Commencez par étudier le fichier /etc/hosts. Ouvrez le fichier avec des privilèges sudo dans votre éditeur de texte :

sudo nano /etc/hosts

Nous devons le configurer de sorte qu’il identifie correctement le nom d’hôte et le FQDN de chaque serveur. Pour le serveur de noms primaire, le fichier ressemblera initialement à ceci:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Nous devons modifier la deuxième ligne pour référencer notre combinaison spécifique d’hôte et de domaine et la faire pointer vers notre adresse IP publique et statique. Nous pouvons ensuite ajouter le nom non qualifié comme alias à la fin. Pour le serveur primaire dans cet exemple, vous modifieriez la deuxième ligne comme suit :

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Nous devrions également modifier le fichier /etc/hostname pour contenir notre nom d’hôte non qualifié :

sudo nano /etc/hostname

ns1

Nous pouvons lire cette valeur dans le système en cours d’exécution puis en tapant :

sudo hostname -F /etc/hostname

Nous voulons effectuer la même procédure sur notre serveur secondaire.

Débutez avec le fichier /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Enregistrez et fermez le fichier lorsque vous avez terminé.

Modifiez ensuite le fichier /etc/hostname. N’oubliez pas de n’utiliser que l’hôte réel (juste ns2 dans notre exemple) pour ce fichier:

sudo nano /etc/hostname

ns2

De nouveau, lisez le fichier pour modifier le système actuel:

sudo hostname -F /etc/hostname

Vos serveurs devraient maintenant avoir leurs définitions d’hôte correctement définies.

Installer Bind sur les deux serveurs de noms

Sur chacun de vos serveurs de noms, vous pouvez maintenant installer Bind, le serveur DNS que nous allons utiliser.

Le logiciel Bind est disponible au sein des dépôts par défaut d’Ubuntu, il nous suffit donc de mettre à jour notre index de paquets local et d’installer le logiciel en utilisant apt. Nous inclurons également la documentation et certains utilitaires communs :

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Exécutez cette commande d’installation sur vos serveurs DNS primaire et secondaire pour acquérir les fichiers appropriés.

Configurer le serveur primaire Bind

Maintenant que nous avons installé le logiciel, nous pouvons commencer par configurer notre serveur DNS sur le serveur primaire.

Configurer le fichier d’options

La première chose que nous allons configurer pour commencer est le fichier named.conf.options.

Le serveur DNS Bind est également connu sous le nom de named. Le fichier de configuration principal se trouve à l’adresse /etc/bind/named.conf. Ce fichier fait appel aux autres fichiers que nous allons effectivement configurer.

Ouvrez le fichier d’options avec les privilèges sudo dans votre éditeur:

sudo nano /etc/bind/named.conf.options

Ci-après, la plupart des lignes commentées ont été supprimées pour des raisons de brièveté, mais en général, le fichier devrait ressembler à ceci après l’installation:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

La principale chose que nous devons configurer dans ce fichier est la récursion. Comme nous essayons de mettre en place un serveur faisant autorité uniquement, nous ne voulons pas activer la récursion sur ce serveur. Nous pouvons désactiver cela dans le bloc options.

Nous allons aussi par défaut ne pas autoriser les transferts. Nous allons remplacer cela dans les spécifications de zones individuelles plus tard :

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Quand vous avez terminé, enregistrez et fermez le fichier.

Configuration du fichier local

La prochaine étape que nous devons prendre est de spécifier les zones que nous souhaitons contrôler ce serveur. Une zone est toute partie du domaine dont la gestion est déléguée à un serveur de noms et qui n’a pas été subdéléguée à d’autres serveurs.

Nous configurons le domaine example.com et nous n’allons pas subdéléguer la responsabilité d’une partie du domaine à d’autres serveurs. La zone couvrira donc l’ensemble de notre domaine.

Pour configurer nos zones, nous devons ouvrir le fichier /etc/bind/named.conf.local avec des privilèges sudo :

sudo nano /etc/bind/named.conf.local

Ce fichier sera initialement vide en dehors des commentaires. Il existe d’autres zones que notre serveur connaît pour la gestion générale, mais celles-ci sont spécifiées dans le fichier named.conf.default-zones.

Pour commencer, nous devons configurer la forward zone pour notre domaine example.com. La forward zone est la résolution conventionnelle nom-IP à laquelle la plupart d’entre nous pensent lorsque nous parlons de DNS. Nous créons un bloc de configuration qui définit la zone de domaine que nous souhaitons configurer :

zone "example.com" {};

Note : De nombreux outils DNS, leurs fichiers de configuration et leur documentation utilisent les termes  » maître  » et  » esclave  » alors que DigitalOcean préfère généralement des descripteurs alternatifs. Pour éviter toute confusion, nous avons choisi d’utiliser les termes « primaire » et « secondaire » pour désigner les relations entre les serveurs, et de n’utiliser « maître » ou « esclave » que lorsqu’une directive de configuration l’exige.

À l’intérieur de ce bloc, nous ajoutons les informations de gestion de cette zone. Nous spécifions la relation de ce serveur DNS avec la zone. C’est type master; dans l’exemple de zone qui suit puisque nous configurons cette machine comme serveur de nom primaire pour toutes nos zones. Nous indiquons également à Bind le fichier qui contient les enregistrements de ressources réels qui définissent la zone.

Nous allons conserver nos fichiers de zone primaire dans un sous-répertoire appelé zones dans le répertoire de configuration de Bind. Nous appellerons notre fichier db.example.com pour emprunter la convention des autres fichiers de zone dans le répertoire Bind. Notre bloc ressemblera à ceci maintenant:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Nous voulons permettre à cette zone d’être transférée vers notre serveur secondaire, nous devons ajouter une ligne comme ceci:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Puis, nous allons définir la zone inverse pour notre domaine.

Un peu à propos des zones inversées

Si l’organisation qui vous a donné vos adresses IP ne vous a pas donné une plage de réseau et ne vous a pas délégué la responsabilité de cette plage, alors votre fichier de zone inversée ne sera pas référencé et sera géré par l’organisation elle-même.

Avec les fournisseurs d’hébergement, le mappage inverse est généralement pris en charge par la société elle-même. Par exemple, avec DigitalOcean, les mappages inversés pour vos serveurs seront automatiquement créés si vous utilisez le FQDN de la machine comme nom de serveur dans le panneau de contrôle. Par exemple, les mappages inversés pour ce tutoriel pourraient être créés en nommant les serveurs comme ceci:

Dans des cas comme ceux-ci, puisque vous n’avez pas été alloué un morceau d’adresses à administrer, vous devriez utiliser cette stratégie. La stratégie décrite ci-dessous est couverte pour être complète et pour la rendre applicable si on vous a délégué le contrôle de plus grands groupes d’adresses contiguës.

Les zones inversées sont utilisées pour connecter une adresse IP à nouveau à un nom de domaine. Cependant, le système de nom de domaine a été conçu à l’origine pour les mappings vers l’avant, donc une certaine réflexion est nécessaire pour adapter cela afin de permettre les mappings inversés.

Les éléments d’information que vous devez garder à l’esprit pour comprendre les mappings inversés sont :

• Dans un domaine, la partie la plus spécifique est de l’adresse est à gauche. Pour une adresse IP, la partie la plus spécifique est à droite.
• La partie la plus spécifique d’une spécification de domaine est soit un sous-domaine, soit un nom d’hôte. Ceci est défini dans le fichier de zone pour le domaine.
• Chaque sous-domaine peut, à son tour, définir plus de sous-domaines ou d’hôtes.

Tous les mappages de zone inverse sont définis sous le domaine spécial in-addr.arpa, qui est contrôlé par l’Internet Assigned Numbers Authority (IANA). Sous ce domaine, il existe un arbre qui utilise des sous-domaines pour mapper chacun des octets d’une adresse IP. Pour s’assurer que la spécificité des adresses IP reflète celle des domaines normaux, les octets des adresses IP sont en fait inversés.

Donc notre serveur DNS primaire, avec une adresse IP de 192.0.2.1, serait inversé pour être lu comme 1.2.0.192. Lorsque nous ajoutons cette spécification d’hôte en tant que hiérarchie existant sous le domaine in-addr.arpa, l’hôte spécifique peut être référencé comme 1.2.0.192.in-addr.arpa.

Puisque nous définissons des hôtes individuels (comme le « 1 » de tête ici) dans le fichier de zone lui-même lorsque nous utilisons le DNS, la zone que nous configurerions serait 2.0.192.in-addr.arpa. Si notre fournisseur de réseau nous a donné un bloc d’adresses /24, disons 192.0.2.0/24, il nous aurait délégué cette portion in-addr.arpa.

Maintenant que vous savez comment spécifier le nom de la zone inverse, la définition réelle est exactement la même que celle de la zone avant. En dessous de la définition de la zone example.com, faites une zone inverse pour le réseau qui vous a été donné. Encore une fois, cela n’est probablement nécessaire que si on vous a délégué le contrôle d’un bloc d’adresses :

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Nous avons choisi de nommer le fichier db.192.0.2. Ceci est spécifique sur ce que la zone configure et est plus lisible que la notation inverse.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Créer le fichier de la zone avant

Nous avons maintenant parlé à Bind de nos zones avant et arrière, mais nous n’avons pas encore créé les fichiers qui définiront ces zones.

Si vous vous souvenez, nous avons spécifié les emplacements des fichiers comme étant dans un sous-répertoire appelé zones. Nous devons créer ce répertoire:

sudo mkdir /etc/bind/zones

Maintenant, nous pouvons utiliser certains des fichiers de zone préexistants dans le répertoire Bind comme modèles pour les fichiers de zone que nous voulons créer. Pour la zone avant, le fichier db.local sera proche de ce dont nous avons besoin. Copiez ce fichier dans le sous-répertoire zones avec le nom utilisé dans le fichier named.conf.local.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Pendant que nous faisons cela, nous pouvons également copier un modèle pour la zone inverse. Nous utiliserons le fichier db.127, car il correspond bien à ce dont nous avons besoin:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Maintenant, ouvrez le fichier de la zone avant avec les privilèges sudo dans votre éditeur de texte:

sudo nano /etc/bind/zones/db.example.com

Le fichier ressemblera à ceci:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

La première chose que nous devons vouloir faire est de modifier l’enregistrement SOA (début de l’autorité) qui commence avec le premier symbole @ et continue jusqu’à la parenthèse de fermeture.

Nous devons remplacer le localhost. par le nom du FQDN de cette machine. Cette partie de l’enregistrement est utilisée pour définir tout serveur de noms qui répondra de manière autoritaire pour la zone en cours de définition. Ce sera la machine que nous configurons maintenant, ns1.example.com. dans notre cas (remarquez le point de fin. C’est important pour que notre entrée s’enregistre correctement !).

Nous voulons également modifier la pièce suivante, qui est en fait une adresse électronique spécialement formatée avec le @ remplacé par un point. Nous voulons que nos emails aillent à un administrateur du domaine, donc l’email traditionnel est [email protected]. Nous le traduirons de façon à ce qu’il ressemble à admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

Le prochain élément que nous devons modifier est le numéro de série. La valeur du numéro de série est la façon dont Bind indique s’il doit envoyer des informations mises à jour au serveur secondaire.

Note : Ne pas incrémenter le numéro de série est l’une des erreurs les plus courantes qui entraîne des problèmes avec les mises à jour de zone. Chaque fois que vous effectuez une modification, vous devez faire sauter le numéro de série.

Une pratique courante consiste à utiliser une convention pour incrémenter le numéro. Une approche consiste à utiliser la date au format AAAAMMJJ avec un numéro de révision pour le jour ajouté à la fin. Ainsi, la première révision effectuée le 5 juin 2014 pourrait avoir un numéro de série de 2014060501 et une mise à jour effectuée plus tard dans la journée pourrait avoir un numéro de série de 2014060502. La valeur peut être un nombre à 10 chiffres.

Il vaut la peine d’adopter une convention pour faciliter l’utilisation, mais pour garder les choses simples pour notre démonstration, nous allons juste définir la nôtre à 5 pour le moment:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Puis, nous pouvons nous débarrasser des trois dernières lignes du fichier (celles en bas qui commencent par @) car nous allons faire les nôtres.

La première chose que nous voulons établir après l’enregistrement SOA sont les serveurs de noms pour notre zone. Nous spécifions le domaine et ensuite nos deux serveurs de noms qui font autorité pour la zone, par nom. Comme ces serveurs de noms seront des hôtes au sein du domaine lui-même, cela aura l’air un peu autoréférentiel.

Pour notre guide, cela ressemblera à ceci. Encore une fois, faites attention aux points de fin !:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Puisque le but d’un fichier de zone est principalement de mapper les noms d’hôtes et les services à des adresses spécifiques, nous n’avons pas encore terminé. Tout logiciel lisant ce fichier de zone voudra savoir où se trouvent les serveurs ns1 et ns2 afin d’accéder aux zones faisant autorité.

Donc, ensuite, nous devons créer les enregistrements A qui associeront ces noms de serveurs de noms aux adresses IP réelles de nos serveurs de noms :

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Maintenant que nous avons les enregistrements A pour résoudre avec succès nos serveurs de noms à leurs adresses IP correctes, nous pouvons ajouter tout enregistrement supplémentaire. Rappelez-vous, nous avons un serveur web sur l’un de nos hôtes que nous voulons utiliser pour servir notre site. Nous ferons pointer les demandes pour le domaine général (example.com dans notre cas) vers cet hôte, ainsi que les demandes pour l’hôte www. Cela ressemblera à ceci:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Vous pouvez ajouter tout hôte supplémentaire que vous devez définir en créant des enregistrements A supplémentaires. Référez-vous à notre guide des bases du DNS pour vous familiariser avec certaines de vos options de création d’enregistrements supplémentaires.

Lorsque vous avez terminé, votre fichier devrait ressembler à quelque chose comme ceci:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Enregistrez et fermez le fichier lorsque vous avez terminé.

Créer le fichier de zone inverse

Maintenant, nous avons la zone avant configurée, mais nous devons configurer le fichier de zone inverse que nous avons spécifié dans notre fichier de configuration. Nous avons déjà créé le fichier au début de la dernière section.

Ouvrez le fichier dans votre éditeur de texte avec les privilèges sudo:

sudo nano db.192.0.2

Le fichier devrait ressembler à ceci:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Nous allons suivre à peu près la même procédure que celle que nous avons suivie pour la zone avant. Tout d’abord, ajustez le nom de domaine, l’email de l’administrateur et le numéro de série pour qu’ils correspondent exactement à ce que vous aviez dans le dernier fichier (le numéro de série peut être différent, mais doit être incrémenté):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Encore, effacez les lignes sous la parenthèse fermante de l’enregistrement SOA. Nous prendrons le dernier octet de chaque adresse IP de notre réseau et le renverrons au FQDN de cet hôte en utilisant un enregistrement PTR. Chaque adresse IP ne devrait avoir qu’un seul enregistrement PTR pour éviter les problèmes dans certains logiciels, vous devez donc choisir le nom d’hôte vers lequel vous souhaitez effectuer le mappage inverse.

Par exemple, si vous avez un serveur de messagerie configuré, vous voulez probablement configurer le mappage inverse vers le nom de messagerie, car de nombreux systèmes utilisent le mappage inverse pour valider les adresses.

Premièrement, nous devons à nouveau configurer nos serveurs de noms :

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Puis, vous utiliserez le dernier octet de l’adresse IP à laquelle vous vous référez et vous le ferez pointer vers le nom de domaine pleinement qualifié avec lequel vous voulez revenir. Pour notre exemple, nous utiliserons ceci:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Lorsque vous aurez terminé, le fichier devrait ressembler à quelque chose comme ceci:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Tester les fichiers et redémarrer le service

La configuration du serveur primaire est maintenant terminée, mais nous devons encore mettre en œuvre nos changements.

Avant de redémarrer notre service, nous devons tester tous nos fichiers de configuration pour nous assurer qu’ils sont configurés correctement. Nous avons quelques outils qui peuvent vérifier la syntaxe de chacun de nos fichiers.

Premièrement, nous pouvons vérifier les fichiers named.conf.local et named.conf.options en utilisant la commande named-checkconf. Puisque ces deux fichiers sont source par le fichier squelette named.conf, il testera la syntaxe des fichiers que nous avons modifiés.

sudo named-checkconf

Si cela revient sans aucun message, cela signifie que les fichiers named.conf.local et named.conf.options sont syntaxiquement valides.

Puis, vous pouvez vérifier vos fichiers de zone individuels en passant le domaine que la zone gère et l’emplacement du fichier de zone à la commande named-checkzone. Ainsi, pour notre guide, vous pourriez vérifier le fichier de zone avant en tapant :

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Si votre fichier n’a aucun problème, il devrait vous dire qu’il a chargé le bon numéro de série et donner le message « OK »;

zone example.com/IN: loaded serial 5OK

Si vous rencontrez d’autres messages, cela signifie que vous avez un problème avec votre fichier de zone. Habituellement, le message est assez descriptif de la partie invalide.

Vous pouvez vérifier la zone inverse en passant l’adresse in-addr.arpa et le nom du fichier. Pour notre démonstration, nous devrions taper ceci:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

De nouveau, cela devrait vous donner un message similaire sur le chargement du numéro de série correct:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Si tous vos fichiers sont vérifiés, vous pouvez redémarrer votre service Bind:

sudo service bind9 restart

Vous devriez vérifier les journaux en tapant:

sudo tail -f /var/log/syslog

Gardez un œil sur ce journal pour vous assurer qu’il n’y a pas d’erreurs.

Configurer le serveur de liaison secondaire

Maintenant que nous avons configuré le serveur primaire, nous pouvons aller de l’avant et obtenir la configuration du serveur secondaire. Ce sera nettement plus facile que pour le serveur primaire.

Configuration du fichier d’options

De nouveau, nous allons commencer par le fichier named.conf.options. Ouvrez-le avec des privilèges sudo dans votre éditeur de texte :

sudo nano /etc/bind/named.conf.options

Nous apporterons à ce fichier les mêmes modifications exactes que celles que nous avons apportées au fichier de notre serveur primaire.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Enregistrez et fermez le fichier lorsque vous avez terminé.

Configuration du fichier de configuration locale

Puis, nous allons configurer le fichier named.conf.local sur le serveur secondaire. Ouvrez-le avec les privilèges sudo dans votre éditeur de texte :

sudo nano /etc/bind/named.conf.local

Ici, nous allons créer chacune de nos spécifications de zone comme nous l’avons fait sur notre serveur primaire. Cependant, les valeurs et certains des paramètres seront différents.

D’abord, nous allons travailler sur la zone forward. Commencez-la de la même manière que vous l’avez fait dans le fichier primaire :

zone "example.com" {};

Cette fois, nous allons définir le type à slave puisque ce serveur agit comme un secondaire pour cette zone. Cela signifie simplement qu’il reçoit ses fichiers de zone par transfert plutôt qu’un fichier sur le système local. De plus, nous allons juste spécifier le nom de fichier relatif au lieu du chemin absolu du fichier de zone.

La raison en est que, pour les zones secondaires, Bind stocke les fichiers /var/cache/bind. Bind est déjà configuré pour chercher dans cet emplacement de répertoire, nous n’avons donc pas besoin de spécifier le chemin.

Pour notre zone forward, ces détails ressembleront à ceci:

zone "example.com" { type slave; file "db.example.com";};

Enfin, au lieu de la directive allow-transfer, nous spécifierons les serveurs primaires, par adresse IP, dont ce serveur acceptera les transferts de zone. Ceci est fait dans une directive appelée masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Cela complète notre spécification de zone forward. Nous pouvons utiliser ce même format exact pour prendre soin de notre spécification de zone inverse:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Quand vous avez terminé, vous pouvez enregistrer et fermer le fichier.

Tester les fichiers et redémarrer le service

Nous n’avons pas réellement à faire une quelconque création de fichier de zone sur la machine secondaire car, comme nous l’avons mentionné précédemment, ce serveur recevra les fichiers de zone du serveur primaire. Nous sommes donc prêts à tester.

Encore, nous devons vérifier la syntaxe du fichier de configuration. Puisque nous n’avons pas de fichiers de zone à vérifier, nous devons seulement utiliser l’outil named-checkconf:

sudo named-checkconf

Si cela renvoie sans aucune erreur, cela signifie que les fichiers que vous avez modifiés n’ont pas d’erreurs de syntaxe.

Si c’est le cas, vous pouvez redémarrer votre service Bind :

sudo service bind9 restart

Vérifiez les journaux sur les serveurs primaire et secondaire en utilisant :

sudo tail -f /var/log/syslog

Vous devriez voir quelques entrées qui indiquent que les fichiers de zone ont été transférés correctement.

Déléguez l’autorité à vos serveurs de noms

Vos serveurs de noms faisant autorité devraient maintenant être complètement configurés. Cependant, vous devez encore déléguer l’autorité de votre domaine à vos serveurs de noms.

Pour ce faire, vous devrez vous rendre sur le site Web où vous avez acheté votre nom de domaine. L’interface et peut-être la terminologie seront différentes selon le registraire de nom de domaine que vous avez utilisé.

Dans les paramètres de votre domaine, recherchez une option qui vous permettra de spécifier les serveurs de noms que vous souhaitez utiliser. Comme nos serveurs de noms sont à l’intérieur de notre domaine, c’est un cas particulier.

Au lieu que le registraire délègue simplement l’autorité pour la zone par l’utilisation d’enregistrements NS, il devra créer un enregistrement glue. Un enregistrement glue est un enregistrement A qui spécifie les adresses IP des serveurs de noms après avoir spécifié les serveurs de noms auxquels il délègue l’autorité.

En général, la délégation ne liste que les serveurs de noms qui traiteront l’autorité du domaine, mais lorsque les serveurs de noms sont dans le domaine lui-même, un enregistrement A est nécessaire pour les serveurs de noms de la zone parent. Si cela ne se produisait pas, les résolveurs DNS seraient coincés dans une boucle parce qu’il ne serait jamais en mesure de trouver l’adresse IP des serveurs de noms du domaine pour suivre le chemin de la délégation.

Vous devez donc trouver une section du panneau de contrôle de votre registraire de domaine qui vous permet de spécifier les serveurs de noms et leurs adresses IP.

À titre de démonstration, le registraire Namecheap a deux sections de serveurs de noms différentes.

Il y a une section appelée « Nameserver Registration » qui vous permet de spécifier les adresses IP pour les serveurs de noms dans votre domaine:

À l’intérieur, vous pourrez entrer les adresses IP des serveurs de noms qui existent dans le domaine:

Cela créera l’enregistrement A qui servent d’enregistrements de colle dont vous avez besoin dans le fichier de zone parent.

Après avoir fait cela, vous devriez être en mesure de changer les serveurs de noms actifs pour les serveurs de votre domaine. Dans NameCheap, cela se fait en utilisant l’option de menu « Configuration du serveur de nom de domaine »:

Ici, vous pouvez lui dire d’utiliser les serveurs de noms que vous avez ajoutés comme serveurs faisant autorité pour votre site:

Les changements peuvent prendre un certain temps à se propager, mais vous devriez voir les données de vos serveurs de noms être utilisées dans les prochaines 24-48 heures pour la plupart des registrars.

Conclusion

Vous devriez maintenant avoir deux serveurs DNS faisant autorité uniquement configurés pour servir vos domaines. Ceux-ci peuvent être utilisés pour stocker les informations de zone pour des domaines supplémentaires au fur et à mesure que vous en acquérez d’autres.

Configurer et gérer vos propres serveurs DNS vous donne le plus de contrôle sur la façon dont les enregistrements DNS sont traités. Vous pouvez apporter des modifications et être sûr que tous les éléments pertinents des données DNS sont à jour à la source. Bien que d’autres solutions DNS puissent faciliter ce processus, il est important de savoir que vous avez des options et de comprendre ce qui se passe dans les solutions plus packagées.