LPIC‐202 Lab 2: Configurer le serveur DNS secondaire sur CentOS 7

Ce laboratoire guide l'étudiant dans la configuration d'un serveur DNS secondaire sur CentOS 7. Il apprend à sécuriser les requêtes DNS en définissant une liste de clients de confiance, à configurer les zones esclaves pour la redondance DNS, et à vérifier la validité des fichiers de configuration avant de démarrer le service BIND.

D'après le document LPIC‐202 Lab 2: Configurer le serveur DNS secondaire sur CentOS 7

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

LPIC‐202 Lab 2: Configurer le serveur DNS secondaire sur CentOS 7

Document source

LPIC‐202 Lab 2: Configurer le serveur DNS secondaire sur CentOS 7

Networking and Systems Administration · PDF · 2 pages

Afficher l'aperçu du document

Consulter le document original →

Ce laboratoire guide l'étudiant dans la configuration d'un serveur DNS secondaire sur CentOS 7. Il apprend à sécuriser les requêtes DNS en définissant une liste de clients de confiance, à configurer les zones esclaves pour la redondance DNS, et à vérifier la validité des fichiers de configuration avant de démarrer le service BIND. Ce TP nécessite un accès administrateur sur un serveur CentOS 7 et une connaissance de base des serveurs DNS et de l'éditeur vi.

Objectifs

  • Configurer un serveur DNS secondaire (esclave) sur CentOS 7.
  • Définir une liste de clients DNS approuvés pour limiter les requêtes récursives.
  • Configurer les zones DNS esclaves en synchronisation avec le serveur principal.
  • Vérifier la validité des fichiers de configuration BIND.
  • Démarrer et activer le service BIND pour qu'il fonctionne au démarrage.
  • Tester la résolution DNS via le serveur secondaire.

Prérequis et préparation

  • Un serveur CentOS 7 configuré avec BIND installé.
  • Accès root ou sudo pour modifier les fichiers de configuration et gérer les services.
  • Connaissances de base sur les serveurs DNS, notamment la notion de serveur maître et esclave.
  • Adresses IP privées des serveurs impliqués (ns1, ns2, host1, host2) déjà définies.
  • Accès à l'éditeur vi pour modifier les fichiers de configuration.

Modifier le fichier named.conf pour définir les clients de confiance et options

Sur le serveur secondaire (ns2), ouvrez le fichier de configuration principal de BIND :

sudo vi /etc/named.conf

Au-dessus du bloc options existant, créez un bloc ACL nommé "trusted" qui liste les adresses IP des serveurs autorisés à faire des requêtes récursives :

acl "trusted" {
        172.20.10.11;    # ns1 - peut être localhost
        10.128.20.12;    # ns2
        172.20.10.101;   # host1
        172.20.10.102;   # host2
};

Ensuite, éditez le bloc options pour :

  • Ajouter l'adresse IP privée de ns2 à la directive listen-on port 53 :
options {
        listen-on port 53 { 127.0.0.1; 172.20.10.12; };
#        listen-on-v6 port 53 { ::1; };
        ...
  • Modifier la directive allow-query pour autoriser les requêtes provenant des clients "trusted" :
allow-query { localhost; trusted; };

Enfin, ajoutez à la fin du fichier la ligne suivante pour inclure la configuration locale des zones :

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

Enregistrez et quittez le fichier. Cette configuration garantit que seules les machines de confiance peuvent interroger le serveur DNS.

Configurer les zones esclaves dans named.conf.local

Modifiez les permissions du dossier /etc/named pour pouvoir éditer les fichiers :

sudo chmod 755 /etc/named

Ouvrez ensuite le fichier de configuration local :

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

Définissez les zones esclaves correspondant aux zones maîtres du serveur principal. Pour chaque zone, indiquez :

  • Le nom de la zone.
  • Le type slave.
  • Le fichier local où seront stockées les données de la zone.
  • L'adresse IP privée du serveur maître dans la directive masters.

Exemple de configuration :

zone "example.com" {
    type slave;
    file "slaves/db.example.com";
    masters { 172.20.10.11; };  # IP privée de ns1
};

zone "10.20.172.in-addr.arpa" {
    type slave;
    file "slaves/db.172.20.10";
    masters { 172.20.10.11; };  # IP privée de ns1
};

Enregistrez et quittez le fichier. Cette étape permet au serveur secondaire de récupérer les données DNS du serveur principal.

Vérification de la configuration et démarrage du service BIND

Avant de lancer le service, vérifiez la validité des fichiers de configuration avec :

sudo named-checkconf

Si aucune erreur n'est signalée, démarrez le service BIND :

sudo systemctl start named

Pour que BIND démarre automatiquement au démarrage du système, activez-le :

sudo systemctl enable named

Le serveur DNS secondaire est maintenant opérationnel et synchronisé avec le serveur principal.

Tester la résolution DNS via le serveur secondaire

Depuis un client de confiance, par exemple host1, testez la résolution DNS en interrogeant le serveur secondaire :

dig @ns2.example.com host2.example.com

Cette commande doit retourner l'adresse IP associée à host2.example.com, prouvant que le serveur secondaire répond correctement aux requêtes.

Résultats attendus

  • Le fichier /etc/named.conf contient un bloc ACL "trusted" listant les IP autorisées.
  • Le bloc options écoute sur l'IP privée de ns2 et autorise les requêtes des clients "trusted".
  • Le fichier /etc/named/named.conf.local définit les zones esclaves avec l'adresse IP du serveur maître.
  • La commande named-checkconf ne retourne aucune erreur.
  • Le service BIND démarre sans problème et est activé au démarrage.
  • La commande dig interrogeant ns2 retourne la résolution correcte pour host2.example.com.

Pièges courants

  • Oublier d'ajouter l'adresse IP privée de ns2 dans la directive listen-on, ce qui empêche le serveur d'écouter sur la bonne interface.
  • Ne pas modifier la directive allow-query pour inclure les clients "trusted", bloquant ainsi les requêtes externes autorisées.
  • Ne pas définir correctement la directive masters dans les zones esclaves, empêchant la synchronisation avec le serveur principal.
  • Oublier de vérifier la configuration avec named-checkconf, ce qui peut laisser passer des erreurs de syntaxe.
  • Ne pas démarrer ou activer le service BIND, rendant le serveur DNS secondaire inopérant.
  • Tester la résolution DNS depuis un client non listé dans la ACL "trusted", ce qui provoquera un refus de requête.

Partager

Commentaires

Aucun commentaire pour le moment. Posez la première question.

Les commentaires sont relus avant publication. Votre e-mail n'est jamais affiché.

← Toutes les révisions