TOC

Comment configurer BIND en tant que serveur DNS de réseau privé sur Debian 9

introduction

Une partie importante de la gestion de la configuration et de l’infrastructure de serveur consiste à maintenir un moyen simple de rechercher les interfaces réseau et les adresses IP par leur 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 les 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 verrons comment configurer un serveur DNS interne, en utilisant le logiciel de serveur de noms BIND (BIND9) sous Debian 9, que vos serveurs peuvent utiliser pour résoudre les noms d’hôte et les adresses IP privés. Cela fournit un moyen central de gérer vos noms d’hôte internes et vos adresses IP privées, ce qui est indispensable lorsque votre environnement s’étend à plusieurs hôtes.

Conditions préalables

Pour compléter ce didacticiel, vous aurez besoin de l’infrastructure suivante. Créez chaque serveur * dans le même centre de données * avec * https: //www.digitalocean.com/docs/networking/private-networking/quickstart/ [mise en réseau privée activée] *:

  • Un nouveau serveur Debian 9 servant de serveur DNS principal, * ns1 *

  • (Recommandé) Un deuxième serveur Debian 9 servant 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 utilisateur + sudo + et un pare-feu en suivant notre Debian 9 guide de configuration initiale du serveur.

Si vous ne connaissez pas bien les concepts DNS, il est recommandé de lire au moins les trois premières parties de notre Introduction à la gestion du 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 désignerons par * 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 * hôte1 * et * hôte2 * 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 *.

  • La mise en réseau privée est activée sur tous ces serveurs (et se trouve sur le sous-réseau + 10.128.0.0 / 16 +. Vous devrez probablement ajuster ceci pour vos serveurs).

  • Tous les serveurs sont connectés à un projet qui s’exécute sur «exemple.com». Étant donné que notre système DNS sera entièrement interne et privé, vous ne devez pas acheter de nom de domaine. Toutefois, l’utilisation d’un domaine que vous possédez peut aider à éviter les conflits avec des domaines pouvant être routés publiquement.

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

Host Role Private FQDN Private IP Address

ns1

Primary DNS Server

ns1.nyc3.example.com

10.128.10.11

ns2

Secondary DNS Server

ns2.nyc3.example.com

10.128.20.12

host1

Generic Host 1

host1.nyc3.example.com

10.128.100.101

host2

Generic Host 2

host2.nyc3.example.com

10.128.200.102

Note

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

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

Installation de BIND sur des serveurs DNS

Note

Sur les deux serveurs DNS, * ns1 * et * ns2 *, mettez à jour le cache du paquet + apt + en tapant:

sudo apt update

Maintenant, installez BIND:

sudo apt install bind9 bind9utils bind9-doc

Définition du mode de liaison sur IPv4

Avant de continuer, définissons BIND sur le mode IPv4 car notre réseau privé utilise exclusivement IPv4. Sur les deux serveurs, éditez le fichier de paramètres par défaut + bind9 + en tapant:

sudo nano /etc/default/bind9

Ajoutez «-4» à la fin du paramètre + OPTIONS +. Cela devrait ressembler à ceci:

/ etc / default / bind9

. . .
OPTIONS="-u bind "

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 primaire

La configuration de BIND consiste en plusieurs fichiers inclus dans le fichier de configuration principal, + named.conf +. Ces noms de fichiers commencent par + named + car il s’agit du nom du processus exécuté par BIND (abréviation de «domain name daemon»). Nous allons commencer par configurer le fichier d’options.

Configuration du fichier d’options

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

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

Au-dessus du bloc + options + existant, créez un bloc new ACL (liste de contrôle d’accès) appelé «approuvé». C’est là que nous définirons une liste de clients à partir desquels nous autoriserons les requêtes DNS récursives (c.-à-d. vos serveurs situés dans le même centre de données que * ns1 *). En utilisant nos exemples d’adresses IP privées, nous ajouterons * ns1 *, * ns2 *, * host1 * et * host2 * à notre liste de clients de confiance:

/etc/bind/named.conf.options - 1 sur 3

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

options {

       . . .

Maintenant que nous avons notre liste de clients DNS de confiance, nous voudrons éditer le bloc + options +. Actuellement, le début du bloc se présente comme suit:

/etc/bind/named.conf.options - 2 sur 3

       . . .
};

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

Sous la directive + directory +, ajoutez les lignes de configuration en surbrillance (et remplacez-les par la bonne adresse IP * ns1 *) afin que cela ressemble à ceci:

/etc/bind/named.conf.options - 3 sur 3

       . . .

};

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

                        # enables resursive queries
         # allows recursive queries from "trusted" clients
          # ns1 private IP address - listen on private network only
             # disable zone transfers by default






       . . .
};

Lorsque vous avez terminé, enregistrez et fermez le fichier + named.conf.options +. La configuration ci-dessus spécifie que seuls vos propres serveurs (les «dignes 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 fichier + named.conf.local + pour le modifier:

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

Mis à part quelques commentaires, le fichier doit être vide. Ici, nous allons spécifier nos zones avant et arrière. * Les zones DNS * désignent une étendue spécifique pour la gestion et la définition des enregistrements DNS. Puisque nos domaines seront tous dans le sous-domaine «nyc3.example.com», nous utiliserons cela comme notre zone de transfert. Les adresses IP privées de nos serveurs se trouvant chacune dans l’espace IP + 10.128.0.0 / 16 +, nous allons définir une zone inverse pour pouvoir définir des recherches inversées dans cette plage.

Ajoutez la zone de transfert avec les lignes suivantes, en remplaçant le nom de la zone par votre propre adresse IP * privée du serveur DNS secondaire * dans la directive + allow-transfer +:

/etc/bind/named.conf.local - 1 sur 2

zone "" {
   type master;
   file "/etc/bind/zones/db."; # zone file path
   allow-transfer { ; };           # ns2 private IP address - secondary
};

En supposant que notre sous-réseau privé soit + 10.128.0.0 / 16 +, ajoutez la zone inverse en ajoutant les lignes suivantes (* Notez que le nom de notre zone inverse commence par «128.10», qui est l’inversion d’octet de «10.128» *):

/etc/bind/named.conf.local - 2 sur 2

   . . .
};

zone ".in-addr.arpa" {
   type master;
   file "/etc/bind/zones/db.";  # 10.128.0.0/16 subnet
   allow-transfer { ; };  # ns2 private IP address - secondary
};

Si vos serveurs couvrent plusieurs sous-réseaux privés mais se trouvent dans le même centre de données, veillez à 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 de transfert

Le fichier de zone de transfert permet de définir les enregistrements DNS pour les recherches DNS directes. En d’autres termes, lorsque le DNS reçoit une requête de nom, par exemple «hôte1.nyc3.exemple.com», il recherche dans le fichier de zone de transfert la résolution de l’adresse IP privée correspondante de * hôte1 *.

Créons le répertoire où nos fichiers de zone résideront. Selon notre configuration * named.conf.local *, cet emplacement devrait être + / etc / bind / zones +:

sudo mkdir /etc/bind/zones

Nous allons baser notre fichier de zone de transfert sur l’exemple de fichier + db.local +. Copiez-le à l’emplacement approprié à l’aide des commandes suivantes:

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

Maintenant, éditons notre fichier de zone de transfert:

sudo nano /etc/bind/zones/db.

Au début, cela ressemblera à quelque chose comme ceci:

/etc/bind/zones/db.nyc3.example.com - original

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

Tout d’abord, vous voudrez éditer l’enregistrement SOA. Remplacez le premier «localhost» par le nom de domaine complet de * ns1 *, puis remplacez «root.localhost» par «admin.nyc3.example.com». Chaque fois que vous éditez un fichier de zone, vous devez incrémenter la valeur * serial * avant de redémarrer le processus + named +. Nous allons l’incrémenter à «3». Cela devrait maintenant ressembler à quelque chose comme ça:

/etc/bind/zones/db.nyc3.example.com - mis à jour 1 sur 3

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

Ensuite, supprimez les trois enregistrements à la fin du fichier (après l’enregistrement SOA). Si vous ne savez pas quelles lignes supprimer, elles sont signalées par 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 par vos propres noms). Notez que la deuxième colonne spécifie qu’il s’agit d’enregistrements «NS»:

/etc/bind/zones/db.nyc3.example.com - mis à jour 2 sur 3

. . .

; name servers - NS records
   IN      NS      ns1..
   IN      NS      ns2..

Ajoutez maintenant les enregistrements A pour vos hôtes appartenant à cette zone. Cela inclut tout serveur dont le nom doit se terminer 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 les enregistrements A pour * ns1 *, * ns2 *, * host1 * et * host2 * comme suit:

/etc/bind/zones/db.nyc3.example.com - mis à jour 3 sur 3

. . .

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

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

Notre dernier exemple de fichier de zone de transfert ressemble à ceci:

/etc/bind/zones/db.nyc3.example.com - mis à jour

$TTL    604800
@       IN      SOA     . admin.. (
                      ; Serial
            604800     ; Refresh
             86400     ; Retry
           2419200     ; Expire
            604800 )   ; Negative Cache TTL
;
; name servers - NS records
    IN      NS      ns1..
    IN      NS      ns2..

; name servers - A records
ns1..          IN      A
ns2..          IN      A

; 10.128.0.0/16 - A records
.        IN      A
.        IN      A

Passons maintenant au (x) fichier (s) de zone inversée.

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

Les fichiers de zone inversée sont ceux où nous définissons les enregistrements DNS PTR pour les recherches DNS inversées. C’est-à-dire que lorsque le DNS reçoit une requête par adresse IP, par exemple "10.128.100.101", il recherche dans le (s) fichier (s) de la zone inverse (s) pour résoudre le nom de domaine complet correspondant, "host1.nyc3.example.com". .

Sur * ns1 *, pour chaque zone inversée spécifiée dans le fichier + named.conf.local +, créez un fichier de zone inversée. Nous baserons notre (nos) fichier (s) de zone inversée (s) sur l’exemple de fichier + db.127 +. Copiez-le à l’emplacement approprié à l’aide des commandes suivantes (en remplaçant le nom du fichier de destination afin qu’il corresponde à votre définition de zone inversée):

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

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

sudo nano /etc/bind/zones/db.

Au début, cela ressemblera à quelque chose comme ceci:

/etc/bind/zones/db.10.128 - original

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

De la même manière que le fichier de zone de transfert, vous souhaiterez modifier l’enregistrement SOA et incrémenter la valeur * série *. Ça devrait ressembler a quelque chose comme ca:

/etc/bind/zones/db.10.128 - mis à jour 1 sur 3

@       IN      SOA     . .. (
                                      ; Serial

                             . . .

Supprimez maintenant les deux enregistrements à la fin du fichier (après l’enregistrement SOA). Si vous ne savez pas quelles lignes supprimer, elles sont signalées par 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 par vos propres noms). Notez que la deuxième colonne spécifie qu’il s’agit d’enregistrements «NS»:

/etc/bind/zones/db.10.128 - mis à jour 2 sur 3

. . .

; name servers - NS records
     IN      NS      ns1..
     IN      NS      ns2..

Ajoutez ensuite les 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 se trouvent tous dans le sous-réseau + 10.128.0.0 / 16 +. Notez que la première colonne comprend les deux derniers octets des adresses IP privées de vos serveurs, en * ordre inversé *. Assurez-vous de substituer des noms et des adresses IP privées pour correspondre à vos serveurs:

/etc/bind/zones/db.10.128 - mis à jour 3 sur 3

. . .

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

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

Notre dernier exemple de fichier de zone inversée ressemble à ce qui suit:

/etc/bind/zones/db.10.128 - mis à jour

$TTL    604800
@       IN      SOA     . admin.nyc3.example.com. (
                                      ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
; name servers
     IN      NS      ns1..
     IN      NS      ns2..

; PTR Records
  IN      PTR     ns1..    ; 10.128.10.11
  IN      PTR     ns2..    ; 10.128.20.12
IN      PTR     .  ; 10.128.100.101
IN      PTR     .  ; 10.128.200.102

Nous avons terminé la modification de nos fichiers. Nous pouvons ensuite vérifier si nos fichiers contiennent des erreurs.

Vérification de 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 ne comportent aucune erreur de syntaxe, vous revenez à l’invite de votre shell et ne voyez aucun message d’erreur. S’il y a des problèmes avec vos fichiers de configuration, consultez le message d’erreur et la section «Configurer le serveur DNS principal», puis essayez à nouveau + 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 argument spécifie le fichier de zone correspondant, qui sont tous deux définis dans + named.conf.local +.

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

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

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

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

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émarrez BIND:

sudo systemctl restart bind9

Si le pare-feu UFW est configuré, 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 maintenant à 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 principal devient indisponible. Heureusement, le serveur DNS secondaire est beaucoup plus facile à configurer.

Sur * ns2 *, éditez le fichier + named.conf.options +:

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

En haut du fichier, ajoutez la liste de contrôle d’accès avec les adresses IP privées de tous vos serveurs de confiance:

/etc/bind/named.conf.options - mis à jour 1 sur 2 (secondaire)

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

options {

       . . .

Sous la directive + directory +, ajoutez les lignes suivantes:

/etc/bind/named.conf.options - mis à jour 2 sur 2 (secondaire)

       recursion yes;
       allow-recursion { trusted; };
       listen-on { ; };      # ns2 private IP address
       allow-transfer { none; };          # disable zone transfers by default

       forwarders {
               8.8.8.8;
               8.8.4.4;
       };

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

Maintenant, éditez le fichier + named.conf.local +:

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

Définissez les zones esclaves correspondant aux zones maîtres sur le serveur DNS principal. Notez que le type est «esclave», le fichier ne contient pas de chemin et 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 sur le serveur DNS principal, veillez à les ajouter toutes ici:

/etc/bind/named.conf.local - mis à jour (secondaire)

zone "" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

zone ".in-addr.arpa" {
   type slave;
   file "db.";
   masters { ; };  # ns1 private IP
};

Enregistrez et fermez le fichier + named.conf.local +.

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

sudo named-checkconf

Une fois cela vérifié, redémarrez BIND:

sudo systemctl restart bind9

Autorisez les connexions DNS au serveur en modifiant les règles de pare-feu UFW:

sudo ufw allow Bind9

Vous disposez maintenant de serveurs DNS principal et secondaire pour la résolution du nom de réseau privé et de l’adresse IP. Vous devez maintenant configurer vos serveurs clients pour qu’ils utilisent vos serveurs DNS privés.

Configuration des clients DNS

Avant que tous vos serveurs de la liste ACL «approuvée» puissent interroger vos serveurs DNS, vous devez configurer chacun d’eux pour qu’ils utilisent * ns1 * et * ns2 * en tant que serveurs de noms. Ce processus varie selon le 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 +.

Ubuntu 18.04 Clients

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 normalisée et de l’appliquer à un logiciel de gestion de réseau dorsal incompatible. Pour configurer DNS, nous devons écrire un fichier de configuration Netplan.

Commencez par rechercher le périphérique associé à votre réseau privé en interrogeant le sous-réseau privé à l’aide de la commande + ip address +:

ip address show to
Output3: : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
          valid_lft forever preferred_lft forever

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 *, ainsi que la zone DNS:

/ etc / netplan 00-private-nameservers.yaml

network:
   version: 2
   ethernets:
       :                                 # Private network interface
           nameservers:
               addresses:
               -                 # Private IP for ns1
               -                 # Private IP for ns2
               search: [  ]  # DNS zone

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, dites à Netplan d’essayer d’utiliser le nouveau fichier de configuration en utilisant + netplan try +. Si des problèmes entraînent une perte de réseau, Netplan annule automatiquement les modifications après un délai d’attente:

sudo netplan try
OutputWarning: Stopping systemd-networkd.service, but it can still be activated by:
 systemd-networkd.socket
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 120 seconds

Si le compte à rebours est mis à jour correctement en bas, la nouvelle configuration est au moins suffisamment fonctionnelle pour ne pas interrompre votre connexion SSH. Appuyez sur * ENTER * pour accepter la nouvelle configuration.

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

sudo systemd-resolve --status

Faites défiler la liste jusqu’à la section correspondant à votre interface réseau privée. Vous devriez d’abord voir les adresses IP privées de vos serveurs DNS énumérées, suivies de quelques valeurs de secours. Votre domaine devrait être dans le «domaine DNS»:

Output. . .
Link 3 (eth1)
     Current Scopes: DNS
      LLMNR setting: yes
MulticastDNS setting: no
     DNSSEC setting: no
   DNSSEC supported: no
        DNS Servers:

                     67.207.67.2
                     67.207.67.3
         DNS Domain:
. . .

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

Ubuntu 16.04 et les clients Debian

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

sudo nano /etc/network/interfaces

À l’intérieur, trouvez la ligne + dns-nameservers +. S’il est attaché à l’interface + lo +, déplacez-le vers votre interface réseau (+ eth0 + ou + eth1 + par exemple). Ensuite, ajoutez vos propres serveurs de noms devant la liste qui s’y trouve actuellement. En dessous de cette ligne, ajoutez une option + dns-search + pointant vers le domaine de base de votre infrastructure. Dans notre cas, cela serait "nyc3.example.com":

/ etc / network / interfaces

   . . .

   dns-nameservers   8.8.8.8


   . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Assurez-vous que le package + resolvconf + est installé sur votre système:

sudo apt update
sudo apt install resolvconf

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

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

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

OutputRTNETLINK answers: No such process
Waiting for DAD... Done

Vérifiez que vos paramètres ont bien é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 recherche:

Output# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.128.10.11
nameserver 10.128.20.12
nameserver 8.8.8.8
search nyc3.example.com

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

Clients CentOS

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

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

Recherchez les options + DNS1 + et + DNS2 + et définissez-les sur les adresses IP privées de vos serveurs de noms primaire et secondaire. Ajoutez un paramètre + DOMAIN + avec le domaine de base de votre infrastructure. Dans ce guide, cela serait «nyc3.example.com»:

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

. . .
DNS1=
DNS2=

. . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant, redémarrez le service de réseau en tapant:

sudo systemctl restart network

La commande peut être suspendue 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 vos serveurs de noms et votre domaine de recherche dans la liste:

/etc/resolv.conf

nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com

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

Test des clients

Utilisez + nslookup + pour vérifier 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 la liste de contrôle d’accès «de confiance».

Pour les clients CentOS, vous devrez peut-être installer l’utilitaire avec:

sudo yum install bind-utils

Pour les clients Debian, vous pouvez installer avec:

sudo apt install dnsutils

Nous pouvons commencer par effectuer une recherche en aval.

Recherche avancée

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

nslookup host1

L’interrogation «hôte1» devient «hôte1.nyc3.exemple.com» car l’option «+ recherche +» 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 à ceci:

OutputServer:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   host1.nyc3.example.com
Address: 10.128.100.101

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

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 une sortie qui ressemble à ceci:

Output11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

Si tous les noms et adresses IP ont la valeur correcte, cela signifie que vos fichiers de zone sont configurés correctement. Si vous recevez des valeurs inattendues, veillez à examiner les fichiers de zone sur votre serveur DNS principal (par exemple, + db.nyc3.example.com + et + db.10.128 +).

Toutes nos félicitations! Vos serveurs DNS internes sont maintenant correctement configurés! Nous allons maintenant couvrir la maintenance de vos enregistrements de zone.

Maintenir les enregistrements DNS

Maintenant que vous avez un DNS interne opérationnel, vous devez conserver vos enregistrements DNS afin qu’ils reflètent avec précision l’environnement de votre 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 souhaiterez l’ajouter au DNS. Voici une liste des étapes à suivre:

Serveur de noms primaire

  • Fichier de zone de transfert: Ajoutez un enregistrement "A" pour le nouvel hôte, incrémentez la valeur de "Série"

  • Fichier de zone inversé: Ajoutez un enregistrement «PTR» pour le nouvel hôte, incrémentez la valeur de «Série».

  • Ajoutez l’adresse IP privée de votre nouvel hôte à la liste de contrôle d’accès «de confiance» (+ named.conf.options)

Testez vos fichiers de configuration:

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

Puis rechargez BIND:

sudo systemctl reload bind9

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

Serveur de noms secondaire

  • Ajoutez l’adresse IP privée de votre nouvel hôte à la liste de contrôle d’accès «de confiance» (+ named.conf.options)

Vérifiez la syntaxe de configuration:

sudo named-checkconf

Puis rechargez BIND:

sudo systemctl reload bind9

Votre serveur secondaire acceptera maintenant les connexions du nouvel hôte.

Configurer un nouvel hôte pour utiliser votre DNS

  • Configurez + / etc / resolv.conf pour utiliser vos serveurs DNS

  • Testez avec + nslookup +

Supprimer l’hôte du DNS

Si vous supprimez un hôte de votre environnement ou souhaitez simplement le retirer du DNS, supprimez simplement tout ce qui a été ajouté lors de l’ajout du serveur au serveur DNS (c’est-à-dire l’inverse des étapes ci-dessus).

Conclusion

Vous pouvez maintenant faire référence 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 besoin de vous souvenir des adresses IP privées et les fichiers seront plus faciles à lire et à comprendre. En outre, vous pouvez désormais modifier vos configurations pour qu’elles pointent vers un nouveau serveur à un emplacement unique, votre serveur DNS principal, au lieu de devoir modifier divers 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 complets privés pour spécifier les connexions réseau, il est * essentiel * que vos serveurs DNS soient correctement gérés. 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 conserver des sauvegardes actives de chacun d’entre eux.

Related