Comment configurer la liaison en tant que serveur DNS faisant autorité uniquement sur Ubuntu 14.04

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

Le serveur DNS Bind est également appelénamed. Le fichier de configuration principal se trouve dans/etc/bind/named.conf. Ce fichier appelle les autres fichiers que nous allons réellement configurer.

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

Ci-dessous, 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:

La principale chose que nous devons configurer dans ce fichier est la récursivité. Étant donné que nous essayons de configurer un serveur faisant uniquement autorité, nous ne souhaitons pas activer la récursion sur ce serveur. Nous pouvons désactiver cette option dans le blocoptions.

Nous allons également par défaut pour ne pas autoriser les transferts. Nous remplacerons cela ultérieurement dans les spécifications de chaque zone:

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

L'étape suivante consiste à spécifier les zones sur lesquelles nous souhaitons contrôler ce serveur. Une zone est une partie du domaine qui est déléguée pour la gestion à un serveur de noms qui n'a pas été sous-délégué à d'autres serveurs.

Nous configurons le domaineexample.com et nous n'allons pas sous-déléguer la responsabilité d'aucune partie du domaine à d'autres serveurs. La zone couvrira donc tout notre domaine.

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

Ce fichier sera initialement vide à côté 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 fichiernamed.conf.default-zones.

Pour commencer, nous devons configurer la zone de transfert pour notre domaineexample.com. La zone de transfert est la résolution classique nom-à-IP à laquelle la plupart d'entre nous pensons quand nous discutons de DNS. Nous créons un bloc de configuration qui définit la zone de domaine que nous souhaitons configurer:

[.note] #Note:Many DNS tools, their configuration files, and documentation use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. To avoid confusion we’ve chosen to use the terms “primary” and “secondary” to denote relationships between servers, and only use “master” or “slave” where a configuration directive requires it.
#

À l'intérieur de ce bloc, nous ajoutons les informations de gestion concernant cette zone. Nous spécifions la relation de ce serveur DNS avec la zone. Il s'agit detype master; dans l'exemple de zone qui suit puisque nous configurons cette machine comme serveur de noms principal pour toutes nos zones. Nous pointons également Bind vers le fichier qui contient les enregistrements de ressources 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 Bind. Nous appellerons notre fichierdb.example.com pour emprunter la convention des autres fichiers de zone dans le répertoire Bind. Notre bloc va ressembler à ça maintenant:

Nous voulons autoriser le transfert de cette zone sur notre serveur secondaire, nous devons ajouter une ligne comme celle-ci:

Ensuite, nous allons définir la zone inverse de votre domaine.

Nous avons déjà parlé à Bind de nos zones de transfert et de retour, mais nous n’avons pas encore créé les fichiers qui définiront ces zones.

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

Désormais, nous pouvons utiliser certains des fichiers de zone préexistants du répertoire Bind comme modèles pour les fichiers de zone à créer. Pour la zone avant, le fichierdb.local sera proche de ce dont nous avons besoin. Copiez ce fichier dans le sous-répertoirezones avec le nom utilisé dans le fichiernamed.conf.local.

Ce faisant, nous pouvons également copier un modèle pour la zone inverse. Nous utiliserons le fichierdb.127, car il correspond étroitement à ce dont nous avons besoin:

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

Le fichier ressemblera à ceci:

La première chose que nous devons faire est de modifier l'enregistrementSOA (début d'autorité) qui commence par le premier symbole@ et continue jusqu'à la parenthèse fermante.

Nous devons remplacer leslocalhost. 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 avec autorité pour la zone en cours de définition. Ce sera la machine que nous configurons maintenant,ns1.example.com. dans notre cas (notez le point de fin. Ceci est important pour que notre entrée s’inscrive correctement!).

Nous voulons également changer l'élément suivant, qui est en fait une adresse e-mail spécialement formatée avec les@ remplacés par un point. Nous voulons que nos e-mails soient envoyés à un administrateur du domaine, donc l'e-mail traditionnel est[email protected]. Nous traduirions ceci pour qu'il ressemble àadmin.example.com.:

La prochaine pièce à éditer est le numéro de série. La valeur du numéro de série est la suivante: 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, vousmustbosse le numéro de série.

Une pratique courante consiste à utiliser une convention pour incrémenter le nombre. 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 la facilité d'utilisation, mais pour garder les choses simples pour notre démonstration, nous allons simplement définir la nôtre sur5 pour l'instant:

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

La première chose que nous souhaitons établir après l'enregistrement SOA, ce sont les serveurs de noms de notre zone. Nous spécifions le domaine, puis nos deux serveurs de noms qui font autorité pour la zone, par nom. Étant donné que ces serveurs de noms seront des hôtes au sein du domaine même, il semblera un peu auto-référentiel.

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

Dans la mesure où l'objectif d'un fichier de zone est principalement de mapper les noms d'hôtes et les services sur des adresses spécifiques, nous n'avons pas encore terminé. Tout logiciel lisant ce fichier de zone va vouloir savoir où se trouvent les serveursns1 etns2 afin d'accéder aux zones faisant autorité.

Ensuite, nous devons créer les enregistrementsA qui associeront ces noms de serveurs de noms aux adresses IP réelles de nos serveurs de noms:

Maintenant que nous avons les enregistrements A pour résoudre avec succès nos serveurs de noms en adresses IP correctes, nous pouvons ajouter des enregistrements supplémentaires. N'oubliez pas que nous souhaitons utiliser un serveur Web sur l'un de nos hôtes pour servir notre site. Nous dirigerons les requêtes pour le domaine général (example.com dans notre cas) vers cet hôte, ainsi que les requêtes pour l'hôtewww. Il ressemblera à ceci:

Vous pouvez ajouter tous les hôtes supplémentaires que vous devez définir en créant des enregistrementsA supplémentaires. Consultez nosDNS basics guide pour vous familiariser avec certaines de vos options de création d'enregistrements supplémentaires.

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

Enregistrez et fermez le fichier lorsque vous avez terminé.

Nous avons maintenant la zone de transfert configurée, mais nous devons configurer le fichier de zone inverse 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:

Le fichier devrait ressembler à ceci:

Nous allons suivre à peu près la même procédure que nous avons fait avec la zone avancée. Tout d’abord, ajustez le nom de domaine, le courrier électronique de l’administrateur et le numéro de série de manière à ce 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é):

Encore une fois, effacez les lignes sous la parenthèse fermante de l'enregistrementSOA. Nous allons prendre le dernier octet de chaque adresse IP de notre plage de réseau et le mapper vers le FQDN de cet hôte en utilisant un enregistrementPTR. Chaque adresse IP ne doit avoir qu'un seul enregistrementPTR pour éviter des problèmes dans certains logiciels, vous devez donc choisir le nom d'hôte vers lequel vous souhaitez inverser le mappage.

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

Premièrement, nous devons redéfinir nos serveurs de noms:

Vous utiliserez ensuite le dernier octet de l’adresse IP à laquelle vous faites référence et vous le dirigerez vers le nom de domaine complet avec lequel vous souhaitez retourner. Pour notre exemple, nous allons utiliser ceci:

Lorsque vous avez terminé, le fichier devrait ressembler à ceci:

Enregistrez et fermez le fichier lorsque vous avez terminé.

La configuration du serveur principal est maintenant terminée, mais nous devons toujours implémenter nos modifications.

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

Tout d'abord, nous pouvons vérifier les fichiersnamed.conf.local etnamed.conf.options en utilisant la commandenamed-checkconf. Puisque ces deux fichiers sont source par le fichier squelettenamed.conf, il testera la syntaxe des fichiers que nous avons modifiés.

Si cela renvoie sans aucun message, cela signifie que les fichiersnamed.conf.local etnamed.conf.options sont syntaxiquement valides.

Ensuite, vous pouvez vérifier vos fichiers de zone individuels en passant le domaine géré par la zone et l'emplacement du fichier de zone à la commandenamed-checkzone. Donc, pour notre guide, vous pouvez vérifier le fichier de zone de transfert en tapant:

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

Si vous rencontrez d'autres messages, cela signifie que vous avez un problème avec votre fichier de zone. Habituellement, le message décrit assez bien quelle partie est invalide.

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

Encore une fois, cela devrait vous donner un message similaire à propos du chargement du numéro de série correct:

Si tous vos fichiers sont en cours d'extraction, vous pouvez redémarrer votre service Bind:

Vous devriez vérifier les journaux en tapant:

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

Encore une fois, nous allons commencer avec le fichiernamed.conf.options. Ouvrez-le avec les privilèges sudo dans votre éditeur de texte:

Nous apporterons exactement les mêmes modifications à ce fichier que celles de notre serveur principal.

Enregistrez et fermez le fichier lorsque vous avez terminé.

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

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

Nous allons d’abord travailler sur la zone avancée. Commencez de la même manière que dans le fichier principal:

Cette fois, nous allons définir lestype surslave puisque ce serveur agit en tant que 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 simplement 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 rechercher dans cet emplacement de répertoire. Il n'est donc pas nécessaire de spécifier le chemin.

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

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

Ceci complète notre spécification de zone de transfert. Nous pouvons utiliser le même format exact pour prendre en charge notre spécification de zone inversée:

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

En réalité, nous n’avons pas à créer le fichier de zone sur la machine secondaire, car, comme nous l’avons déjà mentionné, ce serveur recevra les fichiers de zone du serveur principal. Nous sommes donc prêts à tester.

Encore une fois, nous devrions vérifier la syntaxe du fichier de configuration. Étant donné que nous n’avons aucun fichier de zone à vérifier, nous devons uniquement utiliser l’outilnamed-checkconf:

Si cela retourne sans erreur, cela signifie que les fichiers que vous avez modifiés ne contiennent pas d'erreur de syntaxe.

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

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

Certaines entrées devraient indiquer que les fichiers de zone ont été transférés correctement.