Introduction

Une partie importante de la gestion de la configuration et de l’infrastructure du serveur comprend le maintien d’un moyen facile de rechercher des interfaces réseau et des adresses IP par nom, en configurant un système de noms de domaine (DNS) approprié. L’utilisation de noms de domaine complets (FQDN), au lieu d’adresses IP, pour spécifier des adresses réseau facilite la configuration des services et des applications et augmente la maintenabilité des fichiers de configuration. Configurer votre propre DNS pour votre réseau privé est un excellent moyen d’améliorer la gestion de vos serveurs.

Dans ce tutoriel, nous allons voir comment configurer un serveur DNS interne, en utilisant le logiciel de serveur de noms de liaison (BIND9) sur CentOS 7, qui peut être utilisé par vos serveurs Privés Virtuels (VPS) pour résoudre des noms d’hôtes privés et des adresses IP privées. Cela fournit un moyen central de gérer vos noms d’hôtes internes et vos adresses IP privées, ce qui est indispensable lorsque votre environnement s’étend à plus de quelques hôtes.

La version Ubuntu de ce tutoriel peut être trouvée ici.

Prérequis

Pour terminer ce tutoriel, vous aurez besoin des éléments suivants :

• Certains serveurs qui s’exécutent dans le même centre de données et dont le réseau privé est activé
• Un nouveau VPS pour servir de serveur DNS principal, ns1
• Facultatif : Un nouveau VPS pour servir de serveur DNS secondaire, ns2
• Accès Root à toutes les étapes ci-dessus (étapes 1 à 4 ici)

Si vous n’êtes pas familier avec les concepts DNS, il est recommandé de lire au moins les trois premières parties de notre Introduction à la gestion du DNS.

Exemple d’hôtes

Par exemple, nous supposerons ce qui suit :

• Nous avons deux VPS existants appelés « host1 » et « host2 »
• Les deux VPS existent dans le centre de données nyc3
• Les deux VPS ont un réseau privé activé (et sont sur le sous-réseau 10.128.0.0/16)
• Les deux VPS sont en quelque sorte liés à notre application Web qui fonctionne « example.com « 

Avec ces hypothèses, nous décidons qu’il est logique d’utiliser un schéma de nommage qui utilise »nyc3.example.com  » pour se référer à notre sous-réseau ou zone privée. Par conséquent, le nom de domaine privé entièrement qualifié (FQDN) de host1 sera « host1.nyc3.example.com « . Reportez-vous au tableau suivant les détails pertinents:

host2

Hôte	Rôle	Nom de domaine complet privé	Adresse IP privée
host1	Hôte générique 1	host1.nyc3.example.com	10.128.100.101
Hôte générique 2	host2.nyc3.example.com	10.128.200.102

Remarque : Votre configuration existante sera différente, mais les exemples de noms et d’adresses IP seront utilisés pour montrer comment configurer un serveur DNS pour fournir un DNS interne fonctionnel. Vous devriez pouvoir adapter facilement cette configuration à votre propre environnement en remplaçant les noms d’hôte et les adresses IP privées par les vôtres. Il n’est pas nécessaire d’utiliser le nom de région du centre de données dans votre schéma de nommage, mais nous l’utilisons ici pour indiquer que ces hôtes appartiennent au réseau privé d’un centre de données particulier. Si vous utilisez plusieurs centres de données, vous pouvez configurer un DNS interne dans chaque centre de données respectif.

Notre objectif

À la fin de ce tutoriel, nous aurons un serveur DNS principal, ns1, et éventuellement un serveur DNS secondaire, ns2, qui servira de sauvegarde.

Voici une table avec des exemples de noms et d’adresses IP :

Hôte	Rôle	Nom de domaine complet privé	Adresse IP privée
ns1	Serveur DNS principal	ns1.nyc3.example.com	10.128.10.11
ns2	Serveur DNS secondaire	ns2.nyc3.example.com	10.128.20.12

Commençons par installer notre serveur DNS principal, ns1.

Installer BIND sur les serveurs DNS

Remarque : Le texte surligné en rouge est important ! Il sera souvent utilisé pour désigner quelque chose qui doit être remplacé par vos propres paramètres ou qui doit être modifié ou ajouté à un fichier de configuration. Par exemple, si vous voyez quelque chose comme host1.nyc3.exemple.avec, remplacez-le par le nom de domaine complet de votre propre serveur. De même, si vous voyez host1_private_IP, remplacez-le par l’adresse IP privée de votre propre serveur.

Sur les deux serveurs DNS, ns1 et ns2, installez BIND avec yum :

sudo yum install bind bind-utils

Confirmez l’invite en entrant y.

Maintenant que BIND est installé, configurons le serveur DNS principal.

Configurer le serveur DNS principal

La configuration de BIND se compose de plusieurs fichiers, qui sont inclus à partir du fichier de configuration principal, named.conf. Ces noms de fichiers commencent par « nommé » car c’est le nom du processus qui s’exécute. Nous allons commencer par configurer le fichier d’options.

Configure Bind

Le processus de BIND est connu sous le nom de named. En tant que tel, de nombreux fichiers se réfèrent à « nommé” au lieu de « LIER”.

Sur ns1, ouvrez le fichier named.conf pour l’édition :

sudo vi /etc/named.conf

Au-dessus du bloc options existant, créez un nouveau bloc ACL appelé « trusted ». C’est là que nous définirons la liste des clients à partir desquels nous autoriserons les requêtes DNS récursives (c’est-à-dire vos serveurs qui se trouvent dans le même centre de données que ns1). En utilisant notre exemple d’adresses IP privées, nous ajouterons ns1, ns2, host1 et host2 à notre liste de clients de confiance :

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Maintenant que nous avons notre liste de clients DNS de confiance, nous voudrons modifier le bloc options. Ajoutez l’adresse IP privée de ns1 à la directive listen-on port 53 et commentez la ligne listen-on-v6 :

options { listen-on port 53 { 127.0.0.1; 10.128.10.11; };# listen-on-v6 port 53 { ::1; };...

Sous ces entrées, remplacez la directive allow-transfer par ”aucun » par l’adresse IP privée de ns2. En outre, changez la directive allow-query de « localhost » à ”trusted »:

À la fin du fichier, ajoutez la ligne suivante :

include "/etc/named/named.conf.local";

Maintenant, enregistrez et quittez named.conf. La configuration ci-dessus spécifie que seuls vos propres serveurs (ceux « de confiance”) pourront interroger votre serveur DNS.

Ensuite, nous allons configurer le fichier local, pour spécifier nos zones DNS.

Configurez le fichier local

Sur ns1, ouvrez le fichier named.conf.local pour l’édition:

sudo vi /etc/named/named.conf.local

Le fichier doit être vide. Ici, nous allons spécifier nos zones avant et arrière.

Ajoutez la zone avant avec les lignes suivantes (remplacez le nom de la zone par le vôtre):

zone "nyc3.example.com" { type master; file "/etc/named/zones/db.nyc3.example.com"; # zone file path};

En supposant que notre sous-réseau privé est 10.128.0.0/16, ajoutez la zone inverse par avec les lignes suivantes (notez que notre nom de zone inverse commence par « 128.10 » qui est l’inversion d’octet de ”10.128″):

zone "128.10.in-addr.arpa" { type master; file "/etc/named/zones/db.10.128"; # 10.128.0.0/16 subnet };

Si vos serveurs couvrent plusieurs sous-réseaux privés mais se trouvent dans le même centre de données, assurez-vous de spécifier une zone et un fichier de zone supplémentaires pour chaque sous-réseau distinct. Lorsque vous avez terminé d’ajouter toutes les zones souhaitées, enregistrez et quittez le fichier named.conf.local.

Maintenant que nos zones sont spécifiées dans BIND, nous devons créer les fichiers de zone avant et arrière correspondants.

Créer un fichier de zone de transfert

Le fichier de zone de transfert est l’endroit où nous définissons les enregistrements DNS pour les recherches DNS de transfert. Autrement dit, lorsque le DNS reçoit une requête de nom, « host1.nyc3.example.com ”par exemple, il regardera dans le fichier de zone avant pour résoudre l’adresse IP privée correspondante de host1.

Créons le répertoire où résideront nos fichiers de zone. Selon notre nom.conf.configuration locale, cet emplacement doit être /etc/named/zones:

 
sudo chmod 755 /etc/named
 
sudo mkdir /etc/named/zones
 

Maintenant, éditons notre fichier de zone avant:

sudo vi /etc/named/zones/db.nyc3.example.com 

Tout d’abord, vous voudrez ajouter l’enregistrement SOA. Remplacez le nom de domaine complet ns1 en surbrillance par votre propre nom de domaine complet, puis remplacez le second « nyc3.example.com  » avec votre propre domaine. Chaque fois que vous modifiez un fichier de zone, vous devez incrémenter la valeur série avant de redémarrer le processus named – nous l’incrémenterons à « 3”. Cela devrait ressembler à ceci:

Après cela, ajoutez vos enregistrements de serveur de noms avec les lignes suivantes (remplacez les noms par les vôtres). Notez que la deuxième colonne spécifie qu’il s’agit d’enregistrements « NS” :

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Ajoutez ensuite les enregistrements A pour vos hôtes appartenant à cette zone. Cela inclut tout serveur dont nous voulons terminer par le nom « .nyc3.example.com  » (remplacez les noms et adresses IP privées). En utilisant nos exemples de noms et d’adresses IP privées, nous ajouterons des enregistrements pour ns1, ns2, host1 et host2 comme ceci:

Enregistrez et quittez le fichier db.nyc3.example.com.

Notre dernier exemple de fichier de zone avant ressemble à ce qui suit:

Passons maintenant au(x)fichier(s) de zone inverse.

Créer des fichiers de zone Inverse

Les fichiers de zone inverse sont l’endroit où nous définissons les enregistrements PTR DNS pour les recherches DNS inversées. Autrement dit, lorsque le DNS reçoit une requête par adresse IP, « 10.128.100.101” par exemple, il regardera dans le ou les fichiers de zone inverse pour résoudre le nom de domaine complet correspondant, « host1.nyc3.example.com ”dans ce cas.

Sur ns1, pour chaque zone inverse spécifiée dans le fichier named.conf.local, créez un fichier de zone inverse.

Modifiez le fichier de zone inverse qui correspond à la ou aux zones inversées définies dans named.conf.local:

sudo vi /etc/named/zones/db.10.128 

De la même manière que le fichier de zone avant, remplacez le nom de domaine complet ns1 en surbrillance par votre propre nom de domaine complet, puis remplaceznyc3.example.com  » avec votre propre domaine. Chaque fois que vous modifiez un fichier de zone, vous devez incrémenter la valeur série avant de redémarrer le processus named – nous l’incrémenterons à « 3”. Cela devrait ressembler à ceci:

Après cela, ajoutez vos enregistrements de serveur de noms avec les lignes suivantes (remplacez les noms par les vôtres). Notez que la deuxième colonne spécifie qu’il s’agit d’enregistrements « NS” :

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Ajoutez ensuite des enregistrements PTR pour tous vos serveurs dont les adresses IP se trouvent sur le sous-réseau du fichier de zone que vous modifiez. Dans notre exemple, cela inclut tous nos hôtes car ils sont tous sur le sous-réseau 10.128.0.0/16. Notez que la première colonne se compose des deux derniers octets des adresses IP privées de vos serveurs dans un ordre inversé. Assurez-vous de substituer des noms et des adresses IP privées pour correspondre à vos serveurs :

Enregistrez et quittez le fichier de zone inverse (répétez cette section si vous devez ajouter d’autres fichiers de zone inverse).

Notre dernier exemple de fichier de zone inverse ressemble à ce qui suit:

Vérifier la syntaxe de configuration de BIND

Exécutez la commande suivante pour vérifier la syntaxe des fichiers named.conf* :

sudo named-checkconf

Si vos fichiers de configuration nommés n’ont aucune erreur de syntaxe, vous retournerez à votre invite shell et ne verrez aucun message d’erreur. S’il y a des problèmes avec vos fichiers de configuration, vérifiez le message d’erreur et la section Configurer le serveur DNS principal, puis réessayez named-checkconf.

La commande named-checkzone peut être utilisée pour vérifier l’exactitude de vos fichiers de zone. Son premier argument spécifie un nom de zone et le second spécifie le fichier de zone correspondant, qui sont tous deux définis dans named.conf.local.

Par exemple, pour vérifier le « nyc3.example.com « configuration de la zone de transfert, exécutez la commande suivante (modifiez les noms pour qu’ils correspondent à votre zone de transfert et à votre fichier):

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

Et pour vérifier le « 128.10.in-addr.arpa « configuration de zone inverse, exécutez la commande suivante (modifiez les numéros pour qu’ils correspondent à votre zone inverse et à votre fichier) :

sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128 

Lorsque tous vos fichiers de configuration et de zone ne contiennent aucune erreur, vous devez être prêt à redémarrer le service BIND.

Démarrer BIND

Démarrer BIND:

sudo systemctl start named

Maintenant, vous voudrez l’activer, il démarrera donc au démarrage :

sudo systemctl enable named

Votre serveur DNS principal est maintenant configuré et prêt à répondre aux requêtes DNS. Passons à la création du serveur DNS secondaire.

Configurer le serveur DNS secondaire

Dans la plupart des environnements, il est conseillé de configurer un serveur DNS secondaire qui répondra aux demandes si le serveur principal devient indisponible. Heureusement, le serveur DNS secondaire est beaucoup plus facile à configurer.

Sur ns2, modifiez le fichier named.conf:

sudo vi /etc/named.conf

Remarque: Si vous préférez ignorer ces instructions, vous pouvez copier le fichier named.conf de ns1 et le modifier pour écouter l’adresse IP privée de ns2, et ne pas autoriser les transferts.

Au-dessus du bloc options existant, créez un nouveau bloc ACL appelé « trusted ». C’est là que nous définirons la liste des clients à partir desquels nous autoriserons les requêtes DNS récursives (c’est-à-dire vos serveurs qui se trouvent dans le même centre de données que ns1). En utilisant notre exemple d’adresses IP privées, nous ajouterons ns1, ns2, host1 et host2 à notre liste de clients de confiance :

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Maintenant que nous avons notre liste de clients DNS de confiance, nous voudrons modifier le bloc options. Ajoutez l’adresse IP privée de ns1 à la directive listen-on port 53 et commentez la ligne listen-on-v6 :

options { listen-on port 53 { 127.0.0.1; 10.128.20.12; };# listen-on-v6 port 53 { ::1; };...

Changer la directive allow-query de « localhost” à « trusted »:

...options {... allow-query { trusted; }; # allows queries from "trusted" clients...

À la fin du fichier, ajoutez la ligne suivante:

include "/etc/named/named.conf.local";

Maintenant, enregistrez et quittez named.conf. La configuration ci-dessus spécifie que seuls vos propres serveurs (ceux « de confiance”) pourront interroger votre serveur DNS.

Ensuite, nous allons configurer le fichier local, pour spécifier nos zones DNS.

Enregistrez et quittez named.conf.

Éditez maintenant le fichier named.conf.local :

 
sudo chmod 755 /etc/named
 
sudo vi /etc/named/named.conf.local
 

Définissez les zones esclaves qui correspondent aux zones maîtres sur le serveur DNS principal. Notez que le type est « esclave », que le fichier ne contient pas de chemin d’accès et qu’il existe une directive masters qui doit être définie sur l’adresse IP privée du serveur DNS principal. Si vous avez défini plusieurs zones inversées dans le serveur DNS principal, assurez-vous de les ajouter toutes ici :

Maintenant, enregistrez et quittez named.conf.local.

Exécutez la commande suivante pour vérifier la validité de vos fichiers de configuration :

sudo named-checkconf

Une fois que cela est vérifié, démarrez BIND:

sudo systemctl start named

Activez BIND pour démarrer au démarrage :

sudo systemctl enable named

Maintenant vous avez serveurs DNS primaires et secondaires pour la résolution des noms de réseau privé et des adresses IP. Vous devez maintenant configurer vos serveurs pour qu’ils utilisent vos serveurs DNS privés.

Configurer les clients DNS

Avant que tous vos serveurs de l’ACL  » de confiance  » puissent interroger vos serveurs DNS, vous devez configurer chacun d’eux pour utiliser ns1 et ns2 comme serveurs de noms. Ce processus varie en fonction du système d’exploitation, mais pour la plupart des distributions Linux, il implique l’ajout de vos serveurs de noms au fichier /etc/resolv.conf.

Clients CentOS

Sur les VPS Linux CentOS, RedHat et Fedora, modifiez simplement le fichier resolv.conf:

sudo vi /etc/resolv.conf

Ajoutez ensuite les lignes suivantes en HAUT du fichier (remplacez votre domaine privé et les adresses IP privées ns1 et ns2) :

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

Maintenant, enregistrez et quittez. Votre client est maintenant configuré pour utiliser vos serveurs DNS.

Clients Ubuntu

Sur les VPS Linux Ubuntu et Debian, vous pouvez modifier le fichier head, qui est ajouté au début à resolv.conf au démarrage:

sudo vi /etc/resolvconf/resolv.conf.d/head

Ajoutez les lignes suivantes au fichier (remplacez votre domaine privé et les adresses IP privées ns1 et ns2) :

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

Exécutez maintenant resolvconf pour générer un nouveau fichier resolv.conf :

sudo resolvconf -u

Votre client est maintenant configuré pour utiliser vos serveurs DNS .

Clients de test

Utilisez nslookup — inclus dans le package « bind-utils » — pour tester si vos clients peuvent interroger vos serveurs de noms. Vous devriez pouvoir le faire sur tous les clients que vous avez configurés et qui se trouvent dans l’ACL « de confiance ”.

Recherche Forward

Par exemple, nous pouvons effectuer une recherche forward pour récupérer l’adresse IP de host1.nyc3.example.com en exécutant la commande suivante :

nslookup host1

L’interrogation de « host1 » se développe en « host1.nyc3.example.com en raison de l’option search est définie sur votre sous-domaine privé, et les requêtes DNS tenteront de rechercher ce sous-domaine avant de rechercher l’hôte ailleurs. La sortie de la commande ci-dessus ressemblerait à ce qui suit :

Output:
Server: 10.128.10.11Address: 10.128.10.11#53Name: host1.nyc3.example.comAddress: 10.128.100.101

Recherche inversée

Pour tester la recherche inversée, interrogez le serveur DNS avec l’adresse IP privée de host1 :

nslookup 10.128.100.101

Vous devriez voir la sortie qui ressemble à ce qui suit :

Output:
Server: 10.128.10.11Address: 10.128.10.11#5311.10.128.10.in-addr.arpa name = host1.nyc3.example.com.

Si tous les noms et adresses IP se résolvent aux valeurs correctes, cela signifie que vos fichiers de zone sont correctement configurés. Si vous recevez des valeurs inattendues, assurez-vous de consulter les fichiers de zone sur votre serveur DNS principal (par ex. db.nyc3.example.com et db.10.128).

Félicitations! Vos serveurs DNS internes sont maintenant configurés correctement ! Maintenant, nous allons couvrir la maintenance de vos enregistrements de zone.

Maintien des enregistrements DNS

Maintenant que vous disposez d’un DNS interne fonctionnel, vous devez conserver vos enregistrements DNS afin qu’ils reflètent fidèlement votre environnement de serveur.

Ajout d’un hôte au DNS

Chaque fois que vous ajoutez un hôte à votre environnement (dans le même centre de données), vous voudrez l’ajouter au DNS. Voici une liste des étapes à suivre:

Serveur de noms principal

• Fichier de zone de transfert: Ajoutez un enregistrement « A” pour le nouvel hôte, incrémentez la valeur de « Serial”
• Fichier de zone inverse: Ajoutez un enregistrement « PTR” pour le nouvel hôte, incrémentez la valeur de « Serial”
• Ajoutez l’adresse IP privée de votre nouvel hôte à l’ACL « de confiance” (named.conf.options)

Puis rechargez BIND :

sudo systemctl reload named

Serveur de noms secondaire

• Ajoutez l’adresse IP privée de votre nouvel hôte à l’ACL « de confiance” (named.conf.options)

Puis rechargez BIND:

sudo systemctl reload named

Configurez un Nouvel hôte pour utiliser Votre DNS

• Configurez la résolution.conf pour utiliser vos serveurs DNS
• Test en utilisant nslookup

Suppression de l’hôte du DNS

Si vous supprimez un hôte de votre environnement ou souhaitez simplement le retirer du DNS, supprimez simplement toutes les choses qui ont été ajoutées lorsque vous avez ajouté le serveur au DNS (c’est-à-dire l’inverse des étapes ci-dessus).

Conclusion

Vous pouvez maintenant vous référer aux interfaces réseau privées de vos serveurs par leur nom, plutôt que par leur adresse IP. Cela facilite la configuration des services et des applications car vous n’avez plus à vous souvenir des adresses IP privées et les fichiers seront plus faciles à lire et à comprendre. De plus, vous pouvez désormais modifier vos configurations pour pointer vers un nouveau serveur en un seul endroit, votre serveur DNS principal, au lieu d’avoir à modifier une variété de fichiers de configuration distribués, ce qui facilite la maintenance.

Une fois que vous avez configuré votre DNS interne et que vos fichiers de configuration utilisent des FQDN privés pour spécifier les connexions réseau, il est essentiel que vos serveurs DNS soient correctement entretenus. S’ils deviennent tous deux indisponibles, vos services et applications qui en dépendent cesseront de fonctionner correctement. C’est pourquoi il est recommandé de configurer votre DNS avec au moins un serveur secondaire et de maintenir des sauvegardes fonctionnelles de tous.