Partager via

Résolution des problèmes liés aux serveurs DNS

Essayez notre agent virtuel : il peut vous aider à identifier et à résoudre rapidement les problèmes courants liés au protocole DNS (Server Message Block).

Cet article explique comment résoudre les problèmes sur les serveurs DNS.

Vérifier la configuration IP

  1. Exécutez ipconfig /all dans une invite de commande et vérifiez l’adresse IP, le masque de sous-réseau et la passerelle par défaut.

  2. Vérifiez si le serveur DNS fait autorité pour le nom recherché. Si c’est le cas, consultez Vérification des problèmes liés aux données faisant autorité.

  3. Exécutez la commande suivante:

    nslookup <name> <IP address of the DNS server>

    Par exemple:

    nslookup app1 10.0.0.1

    Si vous recevez une réponse d’échec ou de délai d’attente, consultez Vérification des problèmes de récursivité.

  4. Videz le cache du programme de résolution. Pour ce faire, exécutez la commande suivante dans une fenêtre d’invite de commandes d’administration :

    dnscmd /clearcache

    Ou, dans une fenêtre PowerShell d’administration, exécutez l’applet de commande suivante :

    Clear-DnsServerCache

    Remarque

    Si le serveur fonctionne en tant que client DNS (par exemple, quand il doit résoudre les noms de ses propres opérations), utilisez cette option Clear-DnsClientCache pour effacer le cache du client DNS local. Si vous résolvez des problèmes liés au rôle du serveur en tant que serveur DNS (qui sert des enregistrements DNS à d’autres clients), utilisez cette option Clear-DnsServerCache pour effacer le cache faisant autorité du serveur et l’empêcher de fournir des informations DNS obsolètes.

  5. Répétez l’étape 3.

Vérifier les problèmes de serveur DNS

Journal des événements

Vérifiez les journaux suivants pour déterminer s’il existe des erreurs enregistrées :

  • Application

  • Système

  • Serveur DNS

Tester à l’aide de la requête nslookup

Exécutez la commande suivante et vérifiez si le serveur DNS est accessible à partir des ordinateurs clients.

nslookup <client name> <server IP address>

  • Si le programme de résolution retourne l’adresse IP du client, le serveur n’a aucun problème.

  • Si le programme de résolution retourne une réponse « Échec du serveur » ou « Requête refusée », la zone est probablement mise en pause ou le serveur est éventuellement surchargé. Vous pouvez savoir s’il est mis en pause en vérifiant l’onglet Général des propriétés de zone dans la console DNS.

Si le programme de résolution retourne la réponse « Requête au serveur expirée » ou « Pas de réponse du serveur », le service DNS ne fonctionne probablement pas. Essayez de redémarrer le service serveur DNS en entrant ce qui suit à l’invite de commandes sur le serveur :

net start DNS

Si le problème se produit lorsque le service est en cours d’exécution, il se peut que le serveur n’écoute pas l’adresse IP que vous avez utilisée dans votre requête nslookup. Sous l’onglet Interfaces de la page propriétés du serveur dans la console DNS, les administrateurs peuvent restreindre l’écoute d’un serveur DNS uniquement sur les adresses sélectionnées. Si le serveur DNS a été configuré pour limiter le service à une liste spécifique de ses adresses IP configurées, il est possible que l’adresse IP utilisée pour contacter le serveur DNS ne figure pas dans la liste. Vous pouvez essayer une autre adresse IP dans la liste ou ajouter l’adresse IP à la liste.

Dans de rares cas, le serveur DNS peut avoir une configuration avancée de sécurité ou de pare-feu. Si le serveur se trouve sur un autre réseau accessible uniquement via un hôte intermédiaire (tel qu’un routeur de filtrage de paquets ou un serveur proxy), le serveur DNS peut utiliser un port non standard pour écouter et recevoir des demandes clientes. Par défaut, nslookup envoie des requêtes aux serveurs DNS sur le port UDP 53. Par conséquent, si le serveur DNS utilise un autre port, les requêtes nslookup échouent. Si vous pensez que cela peut être le problème, vérifiez si un filtre intermédiaire est intentionnellement utilisé pour bloquer le trafic sur les ports DNS connus. Si ce n’est pas le cas, essayez de modifier les filtres de paquets ou les règles de port sur le pare-feu pour autoriser le trafic sur le port UDP/TCP 53.

Vérification des problèmes liés aux données faisant autorité

Vérifiez si le serveur qui retourne la réponse incorrecte est un serveur principal pour la zone (le serveur principal standard pour la zone ou un serveur qui utilise l’intégration Active Directory pour charger la zone) ou un serveur qui héberge une copie secondaire de la zone.

Si le serveur est un serveur principal

Le problème peut être dû à une erreur utilisateur lorsque les utilisateurs entrent des données dans la zone. Ou bien, cela peut être dû à un problème qui affecte la réplication Active Directory ou la mise à jour dynamique.

Si le serveur héberge une copie secondaire de la zone

  1. Examinez la zone sur le serveur principal (le serveur à partir duquel ce serveur récupère les transferts de zone).

    Remarque

    Vous pouvez déterminer quel serveur est le serveur principal en examinant les propriétés de la zone secondaire dans la console DNS.

    Si le nom n’est pas correct sur le serveur principal, passez à l’étape 4.

  2. Si le nom est correct sur le serveur principal, vérifiez si le numéro de série sur le serveur principal est inférieur ou égal au numéro de série sur le serveur secondaire. Si tel est le cas, modifiez le serveur principal ou le serveur secondaire afin que le numéro de série sur le serveur principal soit supérieur au numéro de série sur le serveur secondaire.

  3. Sur le serveur secondaire, forcez un transfert de zone à partir de la console DNS ou en exécutant la commande suivante :

    dnscmd /zonerefresh <zone name>

    Par exemple, si la zone est corp.contoso.com, entrez : dnscmd /zonerefresh corp.contoso.com.

  4. Examinez à nouveau le serveur secondaire pour voir si la zone a été transférée correctement. Si ce n’est pas le cas, vous avez probablement un problème de transfert de zone. Pour plus d’informations, consultez Problèmes de transfert de zone.

  5. Si la zone a été transférée correctement, vérifiez si les données sont maintenant correctes. Si ce n’est pas le cas, les données sont incorrectes dans la zone primaire. Le problème peut être dû à une erreur utilisateur lorsque les utilisateurs entrent des données dans la zone. Ou bien, cela peut être dû à un problème qui affecte la réplication Active Directory ou la mise à jour dynamique.

Vérification des problèmes de récursivité

Pour que la récursivité fonctionne correctement, tous les serveurs DNS utilisés dans le chemin d’une requête récursive doivent être en mesure de répondre et de transférer des données correctes. Si ce n’est pas le cas, une requête récursive peut échouer pour l’une des raisons suivantes :

  • La requête expire avant de pouvoir être terminée.

  • Un serveur utilisé pendant la requête ne répond pas.

  • Un serveur utilisé pendant la requête fournit des données incorrectes.

Démarrez la résolution des problèmes sur le serveur utilisé dans votre requête d’origine. Vérifiez si ce serveur transfère des requêtes vers un autre serveur en examinant l’onglet Redirecteurs dans les propriétés du serveur dans la console DNS. Si la case Activer les redirecteurs est cochée et qu’un ou plusieurs serveurs sont répertoriés, ce serveur transfère les requêtes.

Si ce serveur transfère des requêtes à un autre serveur, vérifiez les problèmes qui affectent le serveur auquel ce serveur transfère les requêtes. Pour rechercher des problèmes, consultez Vérifier les problèmes de serveur DNS. Lorsque cette section vous indique d’effectuer une tâche sur le client, effectuez-la sur le serveur à la place.

Si le serveur est sain et peut transférer des requêtes, répétez cette étape et examinez le serveur vers lequel ce serveur transfère les requêtes.

Si ce serveur ne transfère pas les requêtes à un autre serveur, vérifiez si ce serveur peut interroger un serveur racine. Pour ce faire, exécutez la commande suivante :

nslookup
server <IP address of server being examined>
set q=NS

  • Si le programme de résolution retourne l’adresse IP d’un serveur racine, vous avez probablement une délégation rompue entre le serveur racine et le nom ou l’adresse IP que vous essayez de résoudre. Suivez la procédure Test d'une délégation défaillante pour identifier l’emplacement d’une délégation défaillante.

  • Si le programme de résolution retourne une réponse « La requête au serveur a expiré », vérifiez si les indications racines pointent vers des serveurs racines fonctionnels. Pour ce faire, suivez la procédure Pour afficher les indications de racine actuelles. Si les indicateurs racines pointent vers le fonctionnement des serveurs racines, vous pouvez rencontrer un problème réseau ou le serveur peut utiliser une configuration de pare-feu avancée qui empêche le programme de résolution d’interroger le serveur, comme décrit dans la section Vérifier les problèmes du serveur DNS . Il est également possible que la valeur par défaut du délai d’attente récursive soit trop courte.

Tester une délégation rompue

Commencez les tests de la procédure suivante en interrogeant un serveur racine valide. Le test vous guide à travers un processus complet d'interrogation de tous les serveurs DNS, depuis la racine principale jusqu'au serveur que vous testez pour une délégation défaillante.

  1. À l’invite de commandes sur le serveur que vous testez, entrez les éléments suivants :

    nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>

    Remarque

    Le type d'enregistrement de ressource est celui que vous avez demandé dans votre requête d'origine, et le nom de domaine complet est celui pour lequel vous avez fait la requête (terminé par un point).

  2. Si la réponse inclut une liste d’enregistrements de ressources « NS » et « A » pour les serveurs délégués, répétez l’étape 1 pour chaque serveur et utilisez l’adresse IP des enregistrements de ressources « A » comme adresse IP du serveur.

    • Si la réponse ne contient pas d’enregistrement de ressource « NS », une délégation est rompue.

    • Si la réponse contient des enregistrements de ressources « NS », mais aucun enregistrement de ressource « A », entrez la récursivité définie et interrogez individuellement les enregistrements de ressources « A » des serveurs répertoriés dans les enregistrements « NS ». Si vous ne trouvez pas au moins une adresse IP valide d’un enregistrement de ressource « A » pour chaque enregistrement de ressource NS dans une zone, vous disposez d’une délégation rompue.

  3. Si vous déterminez que vous avez une délégation rompue, corrigez-la en ajoutant ou en mettant à jour un enregistrement de ressource « A » dans la zone parente à l’aide d’une adresse IP valide pour un serveur DNS correct pour la zone déléguée.

Pour afficher les indications de racine actuelles

  1. Démarrez la console DNS.

  2. Ajoutez ou connectez-vous au serveur DNS qui a échoué à une requête récursive.

  3. Cliquez avec le bouton droit sur le serveur, puis sélectionnez Propriétés.

  4. Cliquez sur Root Hints.

Vérifiez la connectivité de base aux serveurs racines.

  • Si les indications racine semblent être configurées correctement, vérifiez que le serveur DNS utilisé en cas d'échec de résolution de noms peut pinguer les serveurs racines par leur adresse IP.

  • Si les serveurs racines ne répondent pas au test ping par adresse IP, les adresses IP des serveurs racines peuvent avoir changé. Toutefois, il est rare de voir une reconfiguration des serveurs racines.

Problèmes de transfert de zone

Exécutez les vérifications suivantes :

  • Vérifiez l’Observateur d’événements pour le serveur DNS principal et secondaire.

  • Vérifiez si le serveur principal refuse d’envoyer le transfert pour la sécurité.

  • Vérifiez l’onglet Transferts de zone dans les propriétés de la zone dans la console DNS. Si le serveur restreint les transferts de zone à une liste de serveurs, tels que ceux répertoriés sous l’onglet Serveurs de noms des propriétés de zone, assurez-vous que le serveur secondaire figure sur cette liste. Vérifiez que le serveur est configuré pour envoyer des transferts de zone.

  • Vérifiez que le serveur principal rencontre des problèmes en suivant les étapes décrites dans la section Vérifier les problèmes du serveur DNS . Lorsque vous êtes invité à effectuer une tâche sur le client, effectuez la tâche sur le serveur secondaire à la place.

  • Vérifiez si le serveur secondaire exécute une autre implémentation de serveur DNS, telle que BIND. Si c’est le cas, le problème peut avoir l’une des causes suivantes :

    • Le serveur principal Windows peut être configuré pour envoyer des transferts de zones rapides, mais le serveur secondaire tiers peut ne pas prendre en charge les transferts de zone rapide. Si c’est le cas, désactivez les transferts de zone rapides sur le serveur principal à partir de la console DNS en cochant la case Activer la liaison des secondaires sous l’onglet Avancé des propriétés de votre serveur.

    • Si une zone de recherche vers l’avant sur le serveur Windows contient un type d’enregistrement (par exemple, un enregistrement SRV) que le serveur secondaire ne prend pas en charge, le serveur secondaire peut rencontrer des problèmes lors de l’extraction de la zone.

Vérifiez si le serveur principal exécute une autre implémentation de serveur DNS, telle que BIND. Dans ce cas, il est possible que la zone sur le serveur principal inclut des enregistrements de ressources incompatibles que Windows ne reconnaît pas.

Si le serveur maître ou le serveur secondaire exécute une autre implémentation de serveur DNS, vérifiez les deux serveurs pour vous assurer qu’ils prennent en charge les mêmes fonctionnalités. Vous pouvez vérifier le serveur Windows dans la console DNS sous l’onglet Avancé de la page des propriétés du serveur. En plus de la zone Activer la liaison des secondaires, cette page inclut la liste déroulante Vérification de nom. Cela vous permet de sélectionner l’application de la conformité RFC stricte pour les caractères dans les noms DNS.