Comment configurer BIND en tant que serveur DNS de réseau privé sur Ubuntu 18.04

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 les interfaces réseau et les adresses IP par nom, en configurant un système de L’utilisation de noms de domaine complets (FQDNs), 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 BIND name server (BIND9) sur Ubuntu 18.04, qui peut être utilisé par vos serveurs pour résoudre les noms d’hôte privés et les 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 CentOS de ce tutoriel se trouve ici.,

Prérequis

Pour compléter ce tutoriel, vous aurez besoin de l’infrastructure. Créer chaque serveur dans le même centre de données avec la mise en réseau privée activée:

• Un nouveau serveur Ubuntu 18.04 pour servir de serveur DNS principal, ns1
• (recommandé) un deuxième serveur Ubuntu 18.04 pour servir de serveur DNS secondaire, ns2
• serveurs supplémentaires dans le même centre de données qui utiliseront vos serveurs DNS

sur chacun de ces serveurs, configurez l’accès administratif via un sudo utilisateur et un pare-feu en suivant notre Ubuntu 18.,04 guide de configuration initiale du serveur.

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 DNS.

exemple D’Infrastructure et D’objectifs

pour les besoins de cet article, nous supposerons ce qui suit:

• Nous avons deux serveurs qui seront désignés comme nos serveurs de noms DNS. Nous les appellerons ns1 et ns2 dans ce guide.
• nous avons deux serveurs clients supplémentaires qui utiliseront l’infrastructure DNS que nous créons. Nous appellerons ces host1 et host2 dans ce guide., Vous pouvez en ajouter autant que vous le souhaitez pour votre infrastructure.
• Tous ces serveurs existent dans le même centre de données. Nous supposerons qu’il s’agit du centre de données nyc3.
• tous ces serveurs ont la mise en réseau privée activée (et sont sur le sous-réseau10.128.0.0/16. Vous devrez probablement ajuster cela pour vos serveurs).
• tous les serveurs sont connectés à un projet qui s’exécute sur « example.com ». puisque notre système DNS sera entièrement interne et privé, vous n’avez pas besoin d’acheter un nom de domaine., Cependant, l’utilisation d’un domaine que vous possédez peut aider à éviter des conflits avec les domaines routables.

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

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 facilement adapter 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.

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

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

installer BIND sur les serveurs DNS

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

sur les deux serveurs DNS, ns1 et ns2, mettez à jour le apt cache de paquet en tapant:

sudo apt-get update

maintenant, installez BIND:

sudo apt-get install bind9 bind9utils bind9-doc

réglage Bind en mode IPv4

avant de continuer, définissons BIND en mode IPv4 puisque notre réseau privé utilise exclusivement IPv4. Sur les deux serveurs, modifiez le fichier de paramètres par défautbind9 en tapant:

sudo nano /etc/default/bind9

ajoutez « -4” à la fin du paramètreOPTIONS., Il devrait ressembler à l’exemple suivant:

. . .OPTIONS="-u bind -4"

Enregistrez et fermez le fichier lorsque vous avez terminé.

redémarrez BIND pour implémenter les modifications:

sudo systemctl restart bind9

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

configuration du serveur DNS principal

la configuration de BIND se compose de plusieurs fichiers, qui sont inclus dans le fichier de configuration principal,named.conf., Ces noms de fichiers commencent par named car c’est le nom du processus qui S’exécute (abréviation de”domain name daemon »). Nous allons commencer par configurer le fichier d’options.

Configuration du Fichier d’Options

Sur ns1, ouvrez le named.conf.options fichier pour le modifier:

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

le options bloc, créer une nouvelle ACL (liste de contrôle d’accès) bloc « de confiance”. C’est là que nous définirons une liste de clients à partir desquels nous autoriserons les requêtes DNS récursives (c’est-à-dire, vos serveurs sont 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};options { . . .

Maintenant que nous avons notre liste de confiance des clients DNS, nous allons modifier la balise options bloc. Actuellement, le début du bloc ressemble à ce qui suit:

 . . .};options { directory "/var/cache/bind"; . . .}

Sous la directive directory, ajoutez les lignes de configuration en surbrillance (et remplacez-les par l’adresse IP ns1 appropriée) pour que cela ressemble à ceci:

Lorsque vous avez terminé, enregistrez et fermez la balise named.conf.options fichier. La configuration ci-dessus spécifie que seuls vos propres serveurs (les « de confiance”) pourront interroger votre serveur DNS pour des domaines extérieurs.

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

Configuration du Fichier Local

Sur ns1, ouvrez le named.conf.local fichier pour le modifier:

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

en dehors de quelques commentaires, le dossier doit être vide. Ici, nous allons spécifier nos zones avant et arrière. Les zones DNS désignent une portée spécifique pour la gestion et la définition des enregistrements DNS. Puisque nos domaines seront tous dans le « nyc3.example.com » sous-domaine, nous l’utiliserons comme zone avant., Étant donné que les adresses IP privées de nos serveurs se trouvent chacune dans l’espace IP 10.128.0.0/16, nous allons configurer une zone inverse afin de pouvoir définir des recherches inversées dans cette plage.

ajoutez la zone forward avec les lignes suivantes, en substituant le nom de la zone avec votre propre adresse IP privée et celle du serveur DNS secondaire dans la directiveallow-transfer:

En supposant que notre sous-réseau privé est10.128.0.0/16, ajoutez la zone inverse par les lignes suivantes (notez que notre nom de zone inverse commence par « 128.,10  » qui est l’inversion d’octet de « 10.128 »):

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éation du fichier de zone en avant

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

créons le répertoire où résideront nos fichiers de zone. Selon nos nommé.conf.configuration locale, cet emplacement doit être /etc/bind/zones:

sudo mkdir /etc/bind/zones

nous baserons notre fichier de zone avant sur l’exemple db.local fichier de zone., Le copier au bon endroit avec les commandes suivantes:

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

Maintenant, nous allons modifier notre zone avant du fichier:

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

d’Abord, il ressemblera à quelque chose comme:

tout d’Abord, vous voulez modifier l’enregistrement SOA. Remplacez le premier « localhost « par le FQDN de ns1, puis remplacez » root.localhost « avec  » admin.nyc3.example.com ». 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 allons l’incrémenter à « 3 »., Il devrait maintenant ressembler à quelque chose comme ceci:

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

Ensuite, supprimez les trois enregistrements à la fin du fichier (après l’enregistrement SOA). Si vous n’êtes pas sûr des lignes à supprimer, elles sont marquées d’un commentaire « supprimer cette ligne” ci-dessus.

À la fin du fichier, ajoutez vos enregistrements de serveur de noms avec les lignes suivantes (remplacez les noms avec votre propre). 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.

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

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

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

passons maintenant au fichier(s) de zone inverse.

Création du ou des fichiers de Zone inversée

les fichiers de zone inversée sont l’endroit où nous définissons les enregistrements DNS PTR 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 cherchera dans le ou les fichiers de zone inversée 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 fichiernamed.conf.local, créez un fichier de zone inverse., Nous baserons nos fichiers de zone inversée sur l’exemple db.127 fichier de zone. Copiez-le à l’emplacement approprié avec les commandes suivantes (en remplaçant le nom de fichier de destination pour qu’il corresponde à votre définition de zone inverse):

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

modifiez le fichier de zone inverse qui correspond à la ou aux zones inverses définies dans named.conf.local:il ressemblera à ce qui suit:

de la même manière que le fichier forward zone, vous voudrez éditer L’enregistrement SOA et incrémenter la valeur série. Il devrait ressembler à ceci:

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

Maintenant, supprimer les deux enregistrements à la fin du fichier (après l’enregistrement SOA). Si vous n’êtes pas sûr des lignes à supprimer, elles sont marquées d’un commentaire « supprimer cette ligne” ci-dessus.

À la fin du fichier, ajoutez vos enregistrements de serveur de noms avec les lignes suivantes (remplacez les noms avec votre propre)., 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 PTR enregistrements 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 l’ordre inversé., Assurez-vous de substituer les noms et les adresses IP privées à vos serveurs:

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

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

Nous avons terminé d’éditer nos fichiers, donc ensuite nous pouvons vérifier nos fichiers pour les erreurs.,

vérification de la syntaxe de configuration BIND

exécutez la commande suivante pour vérifier la syntaxe des fichiersnamed.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, examinez le message d’erreur et la section « Configurer le serveur DNS principal”, puis réessayez named-checkconf.

Le named-checkzone commande 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 deuxième argument 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 avant, exécutez la commande suivante (modifiez les noms pour qu’ils correspondent à votre zone avant et à votre fichier):

sudo named-checkzone nyc3.example.com db.nyc3.example.com 

et pour vérifier le « 128.10.in-addr.,arpa  » reverse zone configuration, 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/bind/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.

redémarrer BIND

redémarrer BIND:

sudo systemctl restart bind9

Si vous avez configuré le pare-feu UFW, ouvrez L’accès à BIND en tapant:

sudo ufw allow Bind9

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

configuration du serveur DNS secondaire

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

Sur ns2, modifier la balise named.conf.options fichier:

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

Au début du fichier, ajoutez les ACL avec les adresses IP privées de l’ensemble de vos serveurs approuvés:

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

Sous la directive directory, ajoutez les lignes suivantes:

Enregistrez et fermez le fichier named.conf.options. Ce fichier doit ressembler exactement au fichier named.conf.options de ns1, sauf qu’il doit être configuré pour écouter l’adresse IP privée de ns2.

modifiez maintenant le fichiernamed.conf.local:

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

définissez des zones esclaves qui correspondent aux zones maîtres sur le serveur DNS principal., Notez que le type est « slave », que le fichier ne contient pas de chemin 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 inverses dans le serveur DNS principal, assurez-vous de les ajouter toutes ici:

Maintenant, enregistrez et fermez la balise named.conf.local fichier.,

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

sudo named-checkconf

Une fois cette vérification effectuée, redémarrez BIND:

sudo systemctl restart bind9

autoriser les connexions DNS au serveur en modifiant les règles du pare-feu UFW:

sudo ufw allow Bind9

maintenant, vous avez des serveurs DNS primaires et secondaires pour la résolution du nom du réseau privé et de l’adresse IP. Maintenant, vous devez configurer vos serveurs clients pour utiliser vos serveurs DNS privés.,

configuration des clients DNS

avant que tous vos serveurs dans 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 d’ajouter vos serveurs de noms au fichier /etc/resolv.conf.

clients Ubuntu 18.04

sur Ubuntu 18.04, la mise en réseau est configurée avec Netplan, une abstraction qui vous permet d’écrire une configuration réseau standardisée et de l’appliquer à des logiciels de réseau backend incompatibles., Pour configurer DNS, Nous devons écrire un fichier de configuration Netplan.

tout d’Abord, trouver le périphérique associé à votre réseau privé en interrogeant le sous-réseau privé avec la balise ip address commande:

ip address show to 10.128.0.0/16 

Dans cet exemple, l’interface privée est eth1.

Ensuite, créez un nouveau fichier dans /etc/netplan appelé 00-private-nameservers.yaml:

sudo nano /etc/netplan/00-private-nameservers.yaml

à l’Intérieur, collez le contenu suivant., Vous devrez modifier l’interface du réseau privé, les adresses de vos serveurs DNS ns1 et ns2, et la zone DNS:

Remarque: Netplan utilise le format de sérialisation de données YAML pour ses fichiers de configuration. Étant donné que YAML utilise l’indentation et les espaces pour définir sa structure de données, assurez-vous que votre définition utilise une indentation cohérente pour éviter les erreurs.

Enregistrez et fermez le fichier lorsque vous avez terminé.

ensuite, dites à Netplan de tenter d’utiliser le nouveau fichier de configuration en utilisantnetplan try., S’il y a des problèmes qui causent une perte de réseau, Netplan annulera automatiquement les modifications après un délai d’attente:

sudo netplan try

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socketDo you want to keep these settings?Press ENTER before the timeout to accept the new configurationChanges will revert in 120 seconds

Si le compte à rebours se met à jour correctement en bas, la nouvelle configuration est au moins suffisamment fonctionnelle pour ne pas casser votre connexion SSH. Appuyez sur Entrée pour accepter la nouvelle configuration.

maintenant, vérifiez que le résolveur DNS du système pour déterminer si votre configuration DNS a été appliquée:

sudo systemd-resolve --status

Faites défiler vers le bas jusqu’à ce que vous voyiez la section pour votre interface réseau privée., Vous devriez voir les adresses IP privées de vos serveurs DNS listées en premier, suivies de quelques valeurs de secours. Votre domaine doit être dans le « Domaine DNS”:

Votre client doit maintenant être configuré pour utiliser vos serveurs DNS internes.

Ubuntu 16.04 et les clients Debian

sur Ubuntu 16.04 et les serveurs Linux Debian, vous pouvez modifier le fichier /etc/network/interfaces:

sudo nano /etc/network/interfaces

à l’Intérieur, trouver la ligne dns-nameservers, et propres serveurs de noms devant la liste qui est actuellement là., En dessous de cette ligne, Ajoutez une optiondns-search pointant vers le domaine de base de votre infrastructure. Dans notre cas, ce serait « nyc3.example.com”:

 . . . dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8 dns-search nyc3.example.com . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

maintenant, redémarrez vos services réseau en appliquant les nouvelles modifications avec les commandes suivantes. Assurez-vous de remplacer eth0 avec le nom de votre interface réseau:

sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0 

Cela devrait redémarrer votre réseau sans tomber de votre connexion actuelle., Si cela a fonctionné correctement, vous devriez voir quelque chose comme ceci:

Output
RTNETLINK answers: No such processWaiting for DAD... Done

vérifiez que vos paramètres ont été appliqués en tapant:

cat /etc/resolv.conf

Vous devriez voir vos serveurs de noms dans le fichier /etc/resolv.conf, ainsi que votre domaine de le client est maintenant configuré pour utiliser vos serveurs DNS.

Clients CentOS

sous CentOS, RedHat et Fedora Linux, modifiez le fichier/etc/sysconfig/network-scripts/ifcfg-eth0., Vous devrez peut-être remplacer eth0 par le nom de votre interface réseau principale:

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0 

recherchez les options DNS1 Et DNS2 et définissez-les sur les adresses IP privées de votre Serveurs de noms primaires et secondaires. Ajoutez un paramètreDOMAIN avec le domaine de base de votre infrastructure. Dans ce guide, ce serait de la « nyc3.example.com”:

. . .DNS1=10.128.10.11DNS2=10.128.20.12DOMAIN='nyc3.example.com'. . .

Enregistrez et fermez le fichier lorsque vous avez terminé.,

maintenant, redémarrez le service réseau en tapant:

sudo systemctl restart network

la commande peut se bloquer pendant quelques secondes, mais devrait vous renvoyer à l’invite sous peu.

Vérifiez que vos modifications ont été appliquées en tapant:

cat /etc/resolv.conf

Vous devriez voir le nom de votre serveur et domaine de recherche dans la liste:

nameserver 10.128.10.11nameserver 10.128.20.12search nyc3.example.com

Votre client devrait maintenant pouvoir se connecter et utiliser vos serveurs DNS.

Tests des Clients

Utiliser nslookup pour tester si vos clients peuvent interroger les serveurs de nom., Vous devriez pouvoir faire ceci sur tous les clients que vous avez configurés et êtes dans L’ACL « de confiance”.

Pour CentOS clients, vous devez installer l’utilitaire avec:

sudo yum install bind-utils

Nous pouvons commencer par effectuer une recherche directe.

Recherche directe

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

nslookup host1

l’Interrogation « host1” s’étend à « host1.nyc3.exemple.,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: 127.0.0.53Address: 127.0.0.53#53Non-authoritative answer:Name: host1.nyc3.example.comAddress: 10.128.100.101

ensuite, nous pouvons vérifier les recherches inversées.,

Reverse Lookup

pour tester la reverse lookup, 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
11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.Authoritative answers can be found from:

Si tous les noms et adresses IP se résolvent les fichiers sont configurés correctement. Si vous recevez des valeurs inattendues, assurez-vous de vérifier les fichiers de zone sur votre serveur DNS principal (par exemple 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 avez un DNS interne fonctionnel, vous devez maintenir vos enregistrements DNS afin qu’ils reflètent avec précision votre environnement 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 que vous devez prendre:

Serveur de Nom Principal

• Transférer le fichier de zone: Ajouter Un enregistrement « a” pour le nouvel hôte, incrémenter la valeur de « Série”
• le fichier de zone Inverse: Ajouter un « PTR” record pour le nouvel hôte, incrémenter la valeur de « Série”
• Ajouter votre nouvel hôte de l’adresse IP privée de la « confiance” ACL (named.conf.options

Testez vos fichiers de configuration:

Puis de recharger LIER:

sudo systemctl reload bind9

Votre serveur principal doit être configuré pour le nouvel hôte maintenant.,

Serveur de Nom Secondaire

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

Vérifiez la syntaxe de configuration:

sudo named-checkconf

Puis de recharger BIND:

sudo systemctl reload bind9

Votre serveur secondaire accepte maintenant les connexions de l’hôte.,

configurer un nouvel hôte pour utiliser votre DNS

• configurer/etc/resolv.conf pour utiliser vos serveurs DNS
• tester en utilisantnslookup

Supprimer L’hôte du DNS

Si vous supprimez un hôte de votre environnement ou que vous, 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. En outre, vous pouvez maintenant modifier vos configurations pour pointer vers un nouveau serveur dans 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 noms de domaine 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 de travail des sauvegardes de tous.