Cet article fait partie de notre guide: Guide des bonnes pratiques sur les serveurs Windows

Réseau : comment dépanner un serveur DNS sous Linux et Windows

Les étapes du dépannage d’un serveur DNS comprennent la vérification de l’état du DNS, l’examen de la configuration des zones et l’étude des journaux. Cet article liste les bonnes pratiques valables pour les serveurs Windows comme Linux.

La résolution de noms est un élément essentiel des réseaux modernes. Les services de résolution de noms établissent un lien entre les noms, faciles à mémoriser, et les adresses IP, plus difficiles à mémoriser. Les utilisateurs finaux s’appuient sur la résolution de noms pour naviguer sur les sites web. Les techniciens réseau s’en servent pour cartographier les imprimantes et les lecteurs partagés. Les administrateurs système l’utilisent pour la connexion distante aux serveurs ou aux machines virtuelles.

La première étape du dépannage de la résolution de noms consiste à la comprendre. Le premier article de cette série définit la résolution de noms et fournit des exemples de fonctionnalités telles que le fichier hosts et le DNS. Le deuxième article traite du dépannage des problèmes de résolution de noms du point de vue du client à l’aide d’outils tels que ping, nslookup, host et dig.

Cet article traite du dépannage des services DNS au niveau du serveur. Plus précisément, il traite de la vérification de l’état du service et des fichiers de configuration primaire sur les serveurs DNS Linux et Windows.

Dépannage du DNS sous Linux

Le dépannage de la résolution de noms sur un serveur Linux commence par les bases. Tout d’abord, le service est-il installé et fonctionne-t-il ? Ensuite, les fichiers de zone sont-ils exacts et contiennent-ils les enregistrements de ressources nécessaires à la résolution de l’hôte du réseau ?

Le service de résolution de noms pour Linux est Berkeley Internet Name Domain (BIND), actuellement en version 9.

1/ Vérifier si BIND est installé

Lors du dépannage d’un serveur de résolution de noms, il convient de s’assurer que BIND est installé et en cours d’exécution. Utilisez la commande suivante pour confirmer que BIND9 est installé :

$ named -v

La sortie devrait indiquer que BIND9 est installé et afficher le numéro de version. S’il n’est pas installé, c’est la raison pour laquelle les requêtes de résolution de noms adressées à ce serveur échouent.

Sur Red Hat, Fedora et autres distributions similaires, tapez ce qui suit pour installer BIND9 :

$ sudo dnf install -y bind bind-utils

Sur Ubuntu, Debian et les distributions similaires, tapez ce qui suit :

$ sudo apt install bind9 bind9-utils bind9-dnsutils

La nécessité pour les administrateurs d’installer les divers utilitaires supplémentaires dépend de la manière dont ils comptent utiliser le serveur de résolution de noms.

2/ S’assurer que BIND fonctionne

Si BIND est installé, l'étape suivante consiste à s'assurer que le service fonctionne. Utilisez la commande systemctl avec la syntaxe suivante :

$ sudo systemctl status bind9

Les administrateurs peuvent utiliser les commandes systemctl start, stop, restart, enable et disable pour gérer le service.

N'oubliez pas de configurer le pare-feu pour qu'il autorise le port 53/udp pour les requêtes et 53/tcp pour les transferts de zone.

3/ Vérifier la configuration de la zone

Les répertoires principaux qui stockent les fichiers de configuration de BIND9 sont généralement /etc/bind et /var/cache/bind. Les principaux fichiers de configuration du service sont named.conf, named.conf.default-zones, named.conf.local et named.conf.options. Ces fichiers définissent la manière dont le service de résolution de noms exécute ses tâches.

Notez que les noms exacts des répertoires et des fichiers, ainsi que leur emplacement, peuvent varier en fonction de la distribution. Cela n'est pas rare sur les systèmes Linux. Il peut être utile de rechercher dans les répertoires /etc et /var les chaînes contenant named.

Screenshot d'un exemple de fichier /etc/named.conf
Un exemple de fichier /etc/named.conf.

Les fichiers de zone contiennent les enregistrements de ressources qui relient un nom d’hôte particulier à une adresse IP. Les fichiers de zone se trouvent généralement dans /var/cache/bind. Les enregistrements de ressources standard, tels que les enregistrements de début d’autorité (SOA) et de serveur de noms (NS), sont stockés ici, de même que les enregistrements A et les enregistrements de pointeurs (PTR) utilisés pour les requêtes de résolution de noms. Si le serveur résout des requêtes pour plusieurs zones, chaque zone aura son propre fichier.

Screenshot du fichier named.localhost
Le fichier named.localhost avec les enregistrements SOA, NS, A et AAAA resource.

Vérifiez la configuration du fichier de zone à l’aide de la commande suivante, où zonename est le nom de la zone DNS que les administrateurs sont en train de dépanner :

$ sudo named-checkzone zonename.com db.zonename.com

L’utilitaire named-checkzone vérifie la syntaxe du fichier de zone. Cette vérification permet de tester et de dépanner les fichiers de zone existants et de confirmer la configuration des nouveaux fichiers avant de les charger dans BIND9.

Le résultat devrait indiquer que la zone répond correctement en fournissant le code de sortie 0. Si le contrôle renvoie le code de sortie 1, vérifiez le contenu du fichier de zone à la recherche d’erreurs. Les administrateurs peuvent rencontrer les erreurs suivantes :

  • Le nom de la zone est incorrect.
  • Les fichiers de zone peuvent contenir des enregistrements de ressources A et PTR incorrects.
  • L’enregistrement peut contenir des erreurs typographiques.

Remarque : les administrateurs peuvent juger utile de dépanner à partir du système client en utilisant des outils tels que dig, host et nslookup pour identifier correctement certains problèmes.

Dépannage d’un DNS basé sur un serveur Windows

Les services de domaine Microsoft Active Directory (AD-DS) intègrent plusieurs services pour assurer la sécurité et faciliter la gestion. Le premier de ces services est le DNS et les zones intégrées AD. Cette fonctionnalité permet de répliquer la base de données DNS avec la base de données AD, ce qui constitue une conception de réplication plus complète. Le deuxième service est la mise à jour dynamique des enregistrements A et PTR par le protocole de configuration dynamique des hôtes (DHCP). Le DHCP enregistre le nom d’hôte et l’adresse IP du client auprès du DNS après avoir loué une configuration d’adresse IP, ce qui garantit – avec un peu de chance – que la zone DNS est remplie avec des informations exactes. Étant donné que ces trois services fonctionnent ensemble, il est souvent judicieux de les héberger sur le même serveur.

Tout dépannage de résolution de noms implique nécessairement AD DS et DHCP. Gardez cela à l'esprit lorsque vous examinez les messages de l'observateur d'événements ou lorsque vous tentez de réduire l'étendue des problèmes de résolution de noms.

Plusieurs consoles et cmdlets Windows PowerShell sont disponibles pour dépanner le DNS.

1/ Vérifier que DNS est installé

Tout d’abord, vérifiez que le DNS est installé sur le serveur en consultant le Gestionnaire de serveur ou la console Services. Si nécessaire, ajoutez le rôle DNS et configurez le serveur comme faisant partie du domaine AD.

Screenshot de Server Manager pour accéder à la console DNS
Accédez à la console DNS depuis le menu Tools menu dans Server Manager.

Tous les services, y compris le DNS, sont disponibles dans la console Services du menu Outils du Gestionnaire de serveur. Les administrateurs peuvent vérifier l’état du service et le redémarrer à partir de cette console.

Screenshot de la console Services pour accéder aux paramètres du service DNS
Accédez aux paramètres du service DNS depuis la console Services.

2/ Vérifier les zones

Ouvrez la console DNS Manager pour afficher et gérer les zones existantes. Les administrateurs peuvent également y créer de nouvelles zones et gérer des configurations telles que la réplication de zone, les paramètres de sécurité et la redirection.

Screenshot de la console DNS Manager
La console DNS Manager affiche les zones existantes.

3. Utiliser PowerShell pour dépanner les configurations

Tant que les administrateurs se souviennent des cmdlets et des paramètres appropriés, les environnements de ligne de commande, tels que PowerShell, peuvent être efficaces et généralement plus rapides que la navigation dans une interface graphique. De toute évidence, le principal avantage des interfaces de ligne de commande est l’écriture de scripts. Les administrateurs peuvent même générer leurs propres scripts de dépannage de la résolution de noms.

Plusieurs cmdlets facilitent le dépannage et la création de rapports sur le DNS. Il est particulièrement utile d’afficher les enregistrements de la zone, confirmant que la résolution de noms par le serveur DNS est possible pour le nom demandé.

Voici quelques exemples d’utilisation de PowerShell pour dépanner des configurations ou récupérer des informations.

Effacez le cache du résolveur DNS à l’aide de la cmdlet suivante :

> Clear-DnsServerCache

Utilisez la cmdlet suivante pour récupérer les enregistrements de ressources des serveurs, en confirmant que les enregistrements existent :

> Get-DnsServerResourceRecord -ComputerName DC1 -ZoneName myzone.local

Récupérez les enregistrements A du serveur DNS spécifié en ajoutant le paramètre -RRType A :

> Get-DnsServerResourceRecord -ComputerName DC1 -ZoneName myzone.local -RRType A
Screenshot de la cmdlet Get-DnsServerResourceRecord
La cmdlet Get-DnsServerResourceRecord affiche les informations de zone et les enregistrement de ressources.

4/ Vérifier les configurations DNS

Dans le Gestionnaire de serveur, allez dans le menu Outils et sélectionnez DNS pour ouvrir la console Gestionnaire DNS. Les administrateurs peuvent développer les nœuds pour afficher toutes les zones DNS dont le serveur a connaissance. Voici quelques points à vérifier en fonction du scénario de dépannage :

  • Confirmez que les zones correctes sont répertoriées.
  • Recherchez les erreurs typographiques dans les enregistrements de ressources statiques.
  • Vérifiez que les enregistrements de ressources A et PTR sont corrects.
  • Confirmez que le pare-feu autorise le trafic DNS.

Les administrateurs peuvent également utiliser la console DNS, pour vérifier les propriétés de la zone telles que le balayage et les transitaires. Ces paramètres affectent la manière dont le DNS traite les requêtes de résolution de noms.

La récupération permet de nettoyer les enregistrements DNS. Dans les environnements AD, les clients Windows ou les serveurs DHCP créent dynamiquement des enregistrements de ressources A et PTR. Sans surveillance, le nombre d’enregistrements continue d’augmenter sans que les anciens enregistrements soient supprimés. C’est la raison pour laquelle des propriétés telles que le vieillissement et la récupération sont disponibles dans le DNS.

Le vieillissement identifie les enregistrements de ressources d’un âge donné. Ces enregistrements sont étiquetés comme périmés et sont soumis à la récupération (suppression) après un intervalle de temps spécifié. Veillez à ce que la récupération soit activée sur un serveur DNS de la zone afin de maintenir la zone à une taille gérable.

Screenshot de la manière de configurer le vieillissement et la récupération pour éliminer les enregistrements de ressources périmés
Configurer le vieillissement et la récupération pour éliminer les enregistrements de ressources périmés.

Le transfert envoie les requêtes non résolues à un autre serveur. Cette configuration isole les serveurs DNS internes, qui sont probablement colocalisés avec les contrôleurs de domaine AD, de l’accès direct à l’internet. Au lieu de cela, un serveur DNS désigné, appelé « forwarder », réside dans le sous-réseau blindé du réseau, ou DMZ, qui fait face à l’internet. Les serveurs DNS internes transmettent au forwarder les requêtes relatives aux ressources internet externes.

Screenshot of sur mla manière de configurer des relais pour permettre au service DNS d'envoyer des requêtes
Configurer un ou plusieurs relais pour permettre au service DNS d'envoyer des requêtes directement à des serveurs DNS spécifiques.

Un autre paramètre à vérifier est la redirection conditionnelle. La redirection conditionnelle DNS permet aux administrateurs d’associer des noms de domaine spécifiques à des serveurs DNS connus. Lorsqu’un serveur DNS reçoit une requête liée à ce nom de domaine, la requête est envoyée directement au serveur DNS répertorié sans passer par plusieurs autres serveurs. Assurez-vous que les noms de domaine identifiés sont corrects et que les adresses IP des serveurs DNS appropriés sont fournies.

5/ Recharger la zone

Essayez ensuite de recharger la zone. Les administrateurs peuvent également redémarrer le service DNS. Sachez toutefois que cette opération redémarre également AD DS et peut affecter les systèmes clients. On suppose qu’il y a au moins deux AD DC sur le site pour atténuer l’effet de l’indisponibilité d’un DC à la fois.

6/ Vérifier les journaux de l’observateur d’événements

Vérifiez ensuite les journaux DNS de l’observateur d’événements. Les administrateurs peuvent avoir besoin de regarder les événements AD DS et peut-être même les événements DHCP, et pas seulement les entrées DNS. Recherchez les entrées indiquant des problèmes de démarrage du DNS. Plus important encore, vérifiez les erreurs de réplication dans DNS et AD DS.

Screenshot d'Event Viewer pour afficher les messages DNS
Event Viewer affiche les messages DNS ainsi que les éléments AD et DHCP en rapport.

Windows propose plusieurs interfaces de service DNS. Les administrateurs peuvent gérer le service via la console Services, mais la plupart des dépannages DNS se feront probablement dans la console DNS Manager. Cette console permet de gérer les zones, d’afficher les enregistrements de ressources et de modifier les paramètres du service, tels que la récupération et le transfert. Les zones intégrées AD améliorent la sécurité et les performances de la réplication des zones DNS et permettent une intégration plus étroite entre DNS et DHCP. N’oubliez donc pas de vérifier les paramètres de réplication AD et DHCP lors de la résolution des problèmes DNS.

Pour approfondir sur Administration de réseaux

Close