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

Introduction

Une partie importante de la gestion de la configuration du serveur et de l’infrastructure consiste à maintenir un moyen de trouver les interfaces réseau et les adresses IP par leur nom. Une façon de le faire est de configurer un système de noms de domaine (DNS) approprié. En utilisant des noms de domaine complets (FQDN) au lieu des adresses IP pour spécifier les adresses réseau, on optimise la configuration des services et des applications, et on améliore la maintenabilité des fichiers de configuration. Mettre en place son propre DNS pour son réseau privé est un excellent moyen d’améliorer la gestion de ses serveurs.

Dans ce tutoriel, vous allez configurer un serveur DNS interne à l’aide de deux serveurs Ubuntu 22.04. Vous utiliserez le logiciel de serveur de noms BIND (BIND9) pour résoudre les noms d’hôtes privés et les adresses IP privées. Cela permet de gérer de manière centralisée 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.

Prérequis

Pour réaliser ce tutoriel, vous aurez besoin de l’infrastructure suivante. Assurez-vous de créer chaque serveur dans le même centre de données avec la prise en charge du réseau privé:

• A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
• (Recommandé) Un deuxième serveur Ubuntu 22.04 pour servir de serveur DNS secondaire, ns2.
• Au moins un serveur supplémentaire. Ce guide suppose que vous avez deux serveurs supplémentaires, qui seront appelés serveurs clients. Ces serveurs clients doivent être créés dans le même centre de données où se trouvent vos serveurs DNS.

Sur chacun de ces serveurs, configurez un utilisateur administrateur sudo et configurez un pare-feu en suivant notre guide de configuration initiale du serveur Ubuntu 22.04.

Si vous n’êtes pas familier avec les concepts de DNS, nous vous recommandons de lire au moins les trois premières parties de notre Introduction à la gestion des DNS.

Exemple d’infrastructure et d’objectifs

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

• Vous disposez de deux serveurs qui seront désignés comme vos serveurs de noms DNS. Ce guide les appellera ns1 et ns2.
• Vous disposez de deux serveurs clients supplémentaires qui utiliseront l’infrastructure DNS que vous créez, appelés host1 et host2 dans ce guide. Vous pouvez ajouter autant de serveurs clients que vous le souhaitez.
• Tous ces serveurs se trouvent dans le même centre de données. Ce tutoriel suppose que ce centre de données s’appelle nyc3.
• Tous ces serveurs ont le réseau privé activé et sont sur le sous-réseau 10.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. Ce guide explique comment configurer un système DNS interne et privé, vous pouvez donc utiliser n’importe quel nom de domaine à la place de example.com. Les serveurs DNS tenteront toujours d’acheminer d’abord les demandes en interne, ce qui signifie qu’ils n’essaieront pas d’accéder au domaine donné sur Internet. Cependant, l’utilisation d’un domaine que vous possédez peut aider à éviter les conflits avec les domaines routables publiquement.

Avec ces hypothèses à l’esprit, les exemples de ce guide utiliseront un schéma de dénomination basé sur le sous-domaine nyc3.example.com pour faire référence au sous-réseau ou à la zone privée d’exemple. Par conséquent, le nom de domaine complet privé (FQDN) de host1 sera host1.nyc3.example.com. Le tableau suivant contient les détails pertinents utilisés dans les exemples tout au long de ce guide :

À la fin de ce tutoriel, vous disposerez d’un serveur DNS principal, ns1, et éventuellement d’un serveur DNS secondaire, ns2, qui servira de sauvegarde.

Lorsque vous suivez ce tutoriel, il y aura des moments où vous devrez exécuter certaines commandes sur un serveur spécifique de cette configuration. Toutes les commandes qui doivent être exécutées sur ns1 auront un arrière-plan bleu, comme ceci :

De même, toutes les commandes qui doivent être exécutées sur ns2 auront un arrière-plan rouge :

Et toutes les commandes qui doivent être exécutées sur l’un de vos serveurs clients auront un arrière-plan vert :

Et toutes les commandes qui doivent être exécutées sur plusieurs serveurs auront un arrière-plan standard marine :

Enfin, sachez que chaque fois qu’une commande ou un bloc de code contient du texte mis en évidence comme ceci, cela signifie que ce texte est important. Ce type de mise en évidence sera utilisé tout au long de ce guide pour indiquer les détails qui doivent être remplacés par vos propres paramètres ou que le texte mis en évidence doit être modifié ou ajouté à un fichier de configuration. Par exemple, si un exemple contient quelque chose comme host1.nyc3.example.com, remplacez-le par le nom de domaine complet de votre propre serveur.

Commençons par installer BIND sur vos serveurs DNS primaire et secondaire, ns1 et ns2.

Étape 1 – Installation de BIND sur les serveurs DNS

Sur les deux serveurs DNS, ns1 et ns2, mettez à jour le cache des paquets apt en tapant :

sudo apt update

Ensuite, installez BIND sur chaque machine :

sudo apt install bind9 bind9utils bind9-doc

Le réseau privé de DigitalOcean utilise exclusivement IPv4. Si c’est aussi votre cas, configurez BIND en mode IPv4. Sur les deux serveurs, éditez le fichier de configuration par défaut de named à l’aide de votre éditeur de texte préféré. L’exemple suivant utilise nano :

sudo nano /etc/default/named

Ajoutez -4 à la fin du paramètre OPTIONS :

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

Enregistrez et fermez le fichier lorsque vous avez terminé. Si vous avez utilisé nano pour modifier le fichier, vous pouvez le faire en appuyant sur CTRL + X, Y, puis ENTER.

Redémarrez BIND pour mettre en œuvre les modifications :

sudo systemctl restart bind9

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

Étape 2 – Configuration du serveur DNS principal

La configuration de BIND se compose de plusieurs fichiers inclus depuis le fichier de configuration principal, named.conf. Ces noms de fichiers commencent par named car c’est le nom du processus que BIND exécute (avec named étant l’abréviation de « name daemon », c’est-à-dire « démon de nom de domaine »). Nous commencerons par configurer le fichier named.conf.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 nouveau bloc ACL (liste de contrôle d’accès) appelé trusted. C’est là que vous définirez une liste de clients à partir desquels vous autoriserez les requêtes DNS récursives (c’est-à-dire vos serveurs qui se trouvent dans le même centre de données que ns1). Ajoutez les lignes suivantes pour ajouter ns1, ns2, host1 et host2 à votre liste de clients de confiance, en veillant à remplacer les adresses IP privées d’exemple par celles de vos propres serveurs :

acl "trusted" {
        10.128.10.11;    # ns1 
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Maintenant que vous avez votre liste de clients DNS de confiance, vous pouvez modifier le bloc options. Voici actuellement le début du bloc :

        . . .
};

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

Sous la directive directory, ajoutez les lignes de configuration surlignées (et substituez l’adresse IP privée de ns1 appropriée) :

        . . .

};

options {
        directory "/var/cache/bind";
        
        recursion yes;                 # enables recursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        . . .
};

Remarquez le bloc forwarders, qui comprend deux adresses IP : 8.8.8.8 et 8.8.4.4. Ce bloc définit les forwarders, un mécanisme spécial que BIND utilise pour réduire le trafic sur les liens vers les serveurs de noms externes. BIND peut également utiliser des forwarders pour autoriser les requêtes par des serveurs qui n’ont pas un accès direct à Internet. Cela peut contribuer à accélérer les réponses à ces requêtes en réduisant la charge sur le réseau local.

Les deux adresses IP de ce bloc représentent les résolveurs DNS publics de Google, mais l’adresse IP de n’importe quel serveur de noms récursif public fonctionnera ici. Par exemple, vous pourriez utiliser l’adresse IP du serveur DNS de Cloudflare (1.1.1.1) à la place.

Lorsque vous avez terminé, enregistrez et fermez le fichier named.conf.options. La configuration ci-dessus spécifie que seuls vos propres serveurs (ceux de confiance) pourront interroger votre serveur DNS pour des domaines externes.

Ensuite, vous spécifierez vos zones DNS en configurant le fichier named.conf.local.

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 sera vide. Ici, vous spécifierez vos zones avant et arrière. Les zones DNS désignent une portée spécifique pour gérer et définir les enregistrements DNS. Comme les domaines d’exemple de ce guide se trouvent tous dans le sous-domaine nyc3.example.com, nous l’utiliserons comme zone avant. Étant donné que les adresses IP privées de nos serveurs d’exemple se trouvent chacune dans l’espace d’adressage IP 10.128.0.0/16, l’exemple suivant configurera une zone arrière afin que nous puissions définir des recherches inversées dans cette plage.

Ajoutez la zone avant avec les lignes suivantes, en remplaçant le nom de la zone par le vôtre et l’adresse IP privée du serveur DNS secondaire dans la directive allow-transfer :

. . .

zone "nyc3.example.com" {
    type primary;
    file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
    allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
};

En supposant que notre sous-réseau privé est 10.128.0.0/16, ajoutez la zone arrière avec les lignes suivantes (notez que le nom de notre zone arrière commence par 128.10, qui est l’inversion des octets de 10.128) :

    . . .
};

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

Si vos serveurs s’étendent sur plusieurs sous-réseaux privés mais se trouvent dans le même datacenter, assurez-vous de spécifier une zone et un fichier de zone supplémentaires pour chaque sous-réseau distinct. Une fois que vous avez ajouté toutes les zones souhaitées, enregistrez et fermez le fichier named.conf.local.

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

Création du fichier de zone avant

Le fichier de zone avant est l’endroit où vous définissez les enregistrements DNS pour les recherches DNS avant. C’est-à-dire, lorsque le DNS reçoit une requête de nom, par exemple host1.nyc3.example.com, il consulte le fichier de zone avant pour résoudre l’adresse IP privée correspondante de host1.

Créez le répertoire où se trouveront vos fichiers de zone. Selon la configuration de named.conf.local, cet emplacement devrait être /etc/bind/zones:

sudo mkdir /etc/bind/zones

Nous baserons notre exemple de fichier de zone avant sur le fichier de zone d’exemple db.local. Copiez-le à l’emplacement approprié avec les commandes suivantes:

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

Maintenant, éditez votre fichier de zone avant:

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

Au départ, il contiendra un contenu similaire à celui-ci:

$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 modifier l’enregistrement SOA. Remplacez le premier localhost par le FQDN de ns1, puis remplacez root.localhost par admin.nyc3.example.com. Chaque fois que vous modifiez un fichier de zone, vous devez incrémenter la valeur Serial avant de redémarrer le processus named. Ici, incrémentez-le à 3:

. . .
;
$TTL    604800
@       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 avec des commentaires indiquant supprimer cette ligne dans l’exemple précédent.

À la fin du fichier, 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.

Ensuite, ajoutez les enregistrements A pour vos hôtes qui appartiennent à cette zone. Cela inclut tout serveur dont vous voulez que le nom se termine par .nyc3.example.com (remplacez les noms et adresses IP privées). En utilisant nos noms d’exemple et adresses IP privées, nous ajouterons des enregistrements A pour ns1, ns2, host1 et host2 comme ceci:

. . .

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

Notre fichier de zone avant final contiendra le contenu suivant:

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

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102

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

Maintenant, passons aux fichiers de zone inverse.

Création du fichier de zone inverse(s)

Les fichiers de zone inversée sont utilisés pour définir 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 consulte 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 inversée spécifiée dans le fichier named.conf.local, créez un fichier de zone inversée. Nous baserons nos exemples de fichiers de zone inversée sur le fichier de zone db.127 fourni. BIND utilise ce fichier pour stocker des informations sur l’interface de bouclage locale ; 127 est le premier octet de l’adresse IP qui représente localhost (127.0.0.1). Copiez ce fichier à 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 inversée) :

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

Modifiez le fichier de zone inversée correspondant aux zones inversées définies dans named.conf.local :

sudo nano /etc/bind/zones/db.10.128

Au départ, le fichier contient du contenu comme suit :

$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 pour le fichier de zone avant, vous voudrez modifier l’enregistrement SOA et incrémenter la valeur de série :

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

                              . . .

Ensuite, supprimez 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 dans l’exemple précédent.

Ajoutez à la fin du fichier 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.

Ensuite, ajoutez des enregistrements PTR pour tous vos serveurs dont les adresses IP sont 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 est constituée des deux derniers octets des adresses IP privées de vos serveurs dans l’ordre inverse. Assurez-vous de remplacer les noms et les adresses IP privées pour correspondre à vos serveurs :

. . .

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Votre fichier de zone inverse final ressemblera à ceci :

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

; PTR Records
11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102

Enregistrez et fermez le fichier de zone inverse. Si vous devez ajouter d’autres fichiers de zone inverse, répétez cette section.

Vous avez terminé de modifier vos fichiers, vous pouvez maintenant vérifier vos fichiers pour détecter d’éventuelles erreurs.

Vérification de la syntaxe de configuration BIND

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

sudo named-checkconf

Si vos fichiers de configuration de named ne contiennent pas d’erreurs de syntaxe, il n’y aura pas de messages d’erreur et vous retournerez à l’invite de votre shell. 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.

La commande named-checkzone peut être utilisée pour vérifier la correction de vos fichiers de zone. Son premier argument spécifie le nom de la 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 la configuration de la zone avant nyc3.example.com, exécutez la commande suivante (changez les noms pour correspondre à votre zone avant et votre fichier) :

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

Output
zone nyc3.example.com/IN: loaded serial 3
OK

Et pour vérifier la configuration de la zone inverse 128.10.in-addr.arpa, exécutez la commande suivante (changez les nombres pour correspondre à votre zone inverse et votre fichier) :

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

Lorsque toutes vos configurations et vos fichiers de zone ne contiennent pas d’erreurs, vous serez prêt à redémarrer le service BIND.

Redémarrer BIND

Redémarrez 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 configuration du serveur DNS secondaire.

Étape 3 – Configuration du serveur DNS secondaire

Dans la plupart des environnements, il est conseillé de mettre en place un serveur DNS secondaire qui répondra aux requêtes si le serveur primaire devient inaccessible. Heureusement, la configuration du serveur DNS secondaire est beaucoup moins compliquée que celle du primaire.

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

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

Ajoutez en haut du fichier l’ACL avec les adresses IP privées de tous vos serveurs de confiance:

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

En dessous de la directive directory, ajoutez les lignes suivantes:

    . . .

        recursion yes;
        allow-recursion { trusted; };
        listen-on { 10.128.20.12; };      # 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 devrait être identique au fichier named.conf.options de ns1, à l’exception qu’il devrait être configuré pour écouter l’adresse IP privée de ns2.

Ensuite, éditez le fichier named.conf.local:

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

Définissez les zones secondaires correspondant aux zones primaires du serveur DNS primaire. Notez que le type est secondary, que le fichier ne contient pas de chemin et qu’il y a une directive primaries qui devrait être configurée avec l’adresse IP privée du serveur DNS primaire. Si vous avez défini plusieurs zones inverses sur le serveur DNS primaire, assurez-vous de les ajouter toutes ici:

zone "nyc3.example.com" {
    type secondary;
    file "db.nyc3.example.com";
    primaries { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type secondary;
    file "db.10.128";
    primaries { 10.128.10.11; };  # ns1 private IP
};

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

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

sudo named-checkconf

Si cette commande ne renvoie aucune erreur, redémarrez BIND:

sudo systemctl restart bind9

Ensuite, autorisez les connexions DNS vers le serveur en modifiant les règles du pare-feu UFW.

sudo ufw allow Bind9

Avec cela, vous disposez maintenant de serveurs DNS primaires et secondaires pour la résolution des noms de réseau privé et des adresses IP. Maintenant, vous devez configurer vos serveurs clients pour utiliser vos serveurs DNS privés.

Étape 4 – Configuration des clients DNS

Avant que tous vos serveurs dans la liste ACL trusted puissent interroger vos serveurs DNS, vous devez configurer chacun d’entre eux pour utiliser les serveurs ns1 et ns2 en tant que serveurs de noms.

En supposant que vos serveurs clients utilisent Ubuntu, vous devez trouver quel périphérique est associé à votre réseau privé. Vous pouvez le faire en interrogeant le sous-réseau privé avec la commande ip address. Exécutez la commande suivante sur chacune de vos machines clientes, en remplaçant le sous-réseau surligné par le vôtre:

ip address show to 10.128.0.0/16

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s4
    altname ens4
    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. Les exemples tout au long de cette section feront référence à eth1 en tant qu’interface privée, mais vous devez modifier ces exemples pour refléter les interfaces privées de vos propres serveurs.

Sous Ubuntu 22.04, la configuration du réseau se fait avec Netplan, une abstraction qui vous permet d’écrire une configuration réseau normalisée et de l’appliquer à un logiciel réseau compatible. Pour configurer le DNS, vous devez écrire un fichier de configuration Netplan.

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

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

À l’intérieur, ajoutez les contenus suivants. Vous devrez modifier l’interface du réseau privé, les adresses de vos serveurs DNS ns1 et ns2, ainsi que la zone DNS :

network:
    version: 2
    ethernets:
        eth1:                                    # Private network interface
            nameservers:
                addresses:
                - 10.128.10.11                # Private IP for ns1
                - 10.132.20.12                # Private IP for ns2
                search: [ nyc3.example.com ]    # DNS zone

Sauvegardez et fermez le fichier une fois que vous avez terminé.

Ensuite, indiquez à Netplan d’essayer d’utiliser le nouveau fichier de configuration en utilisant la commande netplan try. Si des problèmes surviennent et entraînent une perte de connexion réseau, Netplan annulera automatiquement les modifications après un délai d’expiration :

sudo netplan try

Output
Warning: 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 ENTRÉE pour accepter la nouvelle configuration.

Maintenant, vérifiez que le résolveur DNS du système a bien appliqué votre configuration DNS :

sudo resolvectl status

Faites défiler jusqu’à trouver la section de votre interface réseau privé. Les adresses IP privées de vos serveurs DNS devraient être répertoriées en premier, suivies de certaines valeurs de repli. Votre domaine devrait être répertorié après DNS Domain :

Output
. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

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

Étape 5 — Test des clients

Utilisez nslookup 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 sont dans la liste trusted.

Vous pouvez commencer par effectuer une recherche directe.

Recherche directe

Pour effectuer une recherche directe afin de récupérer l’adresse IP de host1.nyc3.example.com, exécutez la commande suivante:

nslookup host1

La requête de host1 se développe en host1.nyc3.example.com car l’option search est définie sur votre sous-domaine privé, et les requêtes DNS tenteront de rechercher sur ce sous-domaine avant de chercher l’hôte ailleurs. La commande précédente renverra une sortie semblable à celle-ci:

Output
Server:     127.0.0.53
Address:    127.0.0.53#53

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

Ensuite, vous pouvez vérifier les recherches inverses.

Recherche inverse

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

nslookup 10.128.100.101

Cela devrait renvoyer une sortie semblable à celle-ci:

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 aux valeurs correctes, cela signifie que vos fichiers de zone sont configurés correctement. Si vous recevez des valeurs inattendues, assurez-vous de vérifier les fichiers de zone sur votre serveur DNS primaire (par exemple, `db.nyc3.example.com` et `db.10.128`).

Enfin, ce tutoriel expliquera comment maintenir vos enregistrements de zone.

Étape 6 — Maintien des enregistrements DNS

Maintenant que vous avez un DNS interne fonctionnel, vous devez maintenir vos enregistrements DNS afin qu’ils reflètent correctement 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 primaire

• Fichier de zone avant : Ajoutez un enregistrement `A` pour le nouvel hôte, incrémentez la valeur de `Serial`
• Fichier de zone arrière : 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 à la liste `trusted` (dans `named.conf.options`)

Testez vos fichiers de configuration :

sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Ensuite, rechargez BIND:

sudo systemctl reload bind9

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

Serveur de noms secondaire

• Ajoutez l’adresse IP privée de votre nouvel hôte à la liste ACL trusted (dans named.conf.options)

Vérifiez la syntaxe de la configuration:

sudo named-checkconf

Ensuite, rechargez BIND:

sudo systemctl reload bind9

Votre serveur secondaire acceptera désormais les connexions de votre nouvel hôte.

Configurez le nouvel hôte pour utiliser votre DNS

• Configurez le fichier /etc/resolv.conf pour utiliser vos serveurs DNS
• Testez avec nslookup

Supprimer un hôte du DNS

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

Conclusion

Maintenant, vous pouvez 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 besoin de vous souvenir des adresses IP privées, et les fichiers seront moins difficiles à lire et à comprendre. De plus, vous pouvez maintenant modifier vos configurations pour pointer vers un nouveau serveur à un seul endroit, votre serveur DNS principal, au lieu de devoir modifier plusieurs fichiers de configuration répartis, ce qui optimise 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 de maintenir correctement vos serveurs DNS. Si les deux deviennent 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 chacun d’entre eux.

Si vous souhaitez en savoir plus sur le DNS, nous vous encourageons à consulter notre article Une introduction à la terminologie, aux composants et aux concepts du DNS.