Conseils de résolution des problèmes DNS

Essayez notre agent virtuel : il peut vous aider à identifier et à résoudre rapidement les problèmes DNS courants.

Cette solution est conçue pour vous aider à résoudre les problèmes liés aux scénarios DNS (Domain Name System). Vous pouvez trier les problèmes de résolution des problèmes DNS dans les catégories côté serveur et côté client.

Liste de pour la résolution des problèmes

Problèmes côté serveur

  • Configuration IP
  • Serveur DNS
  • Données faisant autorité
  • Récursivité
  • Transfert de zone

Problèmes côté client

  • Configuration IP
  • Connectivité réseau

Problèmes courants et solutions

Stratégie de prise en charge de la mise en cache côté client DNS sur les clients DNS

Windows contient un cache DNS côté client. Nous vous recommandons de ne pas désactiver la mise en cache côté client DNS sur les clients DNS. Une configuration dans laquelle la mise en cache côté client DNS est désactivée n’est pas prise en charge.

Microsoft ne garantit pas qu’une résolution sera trouvée pour les problèmes qui impliquent des appareils ou des configurations non pris en charge. Si aucune solution n’est trouvée, le coût d’une enquête sur l’incident n’est pas remboursé. S’il n’est pas convenu qu’une solution n’est pas garantie, Support Microsoft ne résout pas le problème et remboursera le coût de l’enquête sur l’incident.

Les enregistrements DNS sont manquants dans une zone DNS

Ce problème peut avoir l’une des causes suivantes.

Le nettoyage DNS est mal configuré

Si des enregistrements DNS sont manquants dans les zones DNS, le nettoyage est la cause la plus courante. Même les ordinateurs Windows qui ont des serveurs DNS affectés statiquement enregistrent leurs enregistrements toutes les 24 heures. Vérifiez si les intervalles d’absence d’actualisation et d’actualisation sont trop bas. Par exemple, si ces valeurs sont toutes deux inférieures à 24 heures, vous perdez des enregistrements DNS.

Pour résoudre ce problème et comprendre les intervalles d’absence d’actualisation et d’actualisation, consultez Utilisation du vieillissement et du nettoyage DNS.

L’enregistrement « A » de l’hôte est supprimé lorsque l’adresse IP est modifiée

Parfois, l’enregistrement « A » de l’hôte est supprimé sur le serveur DNS d’origine une fois que l’enregistrement « A » de l’hôte est inscrit sur l’adresse IP du serveur DNS nouvellement configurée (DNS intégré Active Directory). Du point de vue de l’utilisateur, tout ce qui dépend de la résolution de noms est rompu. Lorsque l’adresse IP du serveur DNS est modifiée sur le client, le client envoie une mise à jour soa (Start of Authority) pour supprimer son enregistrement « A » du serveur DNS précédent. Ensuite, il envoie une autre mise à jour pour inscrire son enregistrement « A » sur le nouveau serveur DNS.

Le problème se produit dans les zones intégrées à Active Directory. Des problèmes se produisent lorsque l’adresse IP du serveur DNS est modifiée sur le client. Lorsque l’adresse IP change, le client envoie une demande d’inscription au nouveau serveur et envoie une demande de suppression au serveur précédent. Étant donné que les deux serveurs sont déjà synchronisés, les enregistrements ne sont pas inscrits. Sur le serveur précédent, le service DNS supprime l’enregistrement « A », puis la suppression est répliquée sur le nouveau serveur. Par conséquent, l’enregistrement est supprimé sur les deux serveurs.

Les clients DHCP qui utilisent l’option DHCP 81 annulent l’inscription des enregistrements de l’hôte « A » pendant l’inscription « AAAA » de l’hôte

Ce problème se produit si les ordinateurs clients DHCP utilisent des cartes réseau ISATAP ou 6to4, et que les clients DNS et les serveurs DNS sont configurés pour mettre à jour dynamiquement les enregistrements DNS. En raison de cette configuration, l’option DHCP 81 (également appelée option FQDN client) est activée sur les clients et les serveurs. Dans ce cas, le serveur DHCP peut créer l’enregistrement « A » DNS (IPv4) du client. Ensuite, le client crée son enregistrement « AAAA » (IPv6). Toutefois, dans le cadre de cette opération, le client envoie d’abord un enregistrement « A » mis à jour qui a une durée de vie (TTL) de 0. Par conséquent, le serveur DNS supprime l’enregistrement « A » du client pendant qu’il inscrit l’enregistrement « AAAA ».

Pour contourner ce comportement, évitez de configurer les clients DHCP qui utilisent ces adaptateurs pour mettre à jour dynamiquement les enregistrements DNS lorsque les serveurs DHCP sont déjà configurés pour le faire.

Remarque

Pour plus d’informations sur l’option DHCP 81, consultez Comportement d’inscription d’enregistrement DNS inattendu si le serveur DHCP utilise « Toujours mettre à jour dynamiquement les enregistrements DNS ». Cet article décrit un problème différent, mais en explique plus sur l’option DHCP 81.

La mise à jour du protocole de mise à jour dynamique DNS vers les enregistrements DNS existants échoue

La mise à jour du protocole de mise à jour dynamique DNS vers les enregistrements existants échoue. En raison de ce problème, le processus de nettoyage DNS considère les enregistrements comme étant anciens et les supprime.

Dans le cas d’un service qui nécessite un enregistrement SRV, le service Netlogon local enregistre les événements « ID d’événement 577X » lorsqu’il ne peut pas inscrire d’enregistrements SRV. Par exemple, si le service Netlogon d’un contrôleur de domaine déclenche une mise à jour dynamique pour son enregistrement SRV LDAP et que cette mise à jour échoue, le service Netlogon enregistre un événement sur le contrôleur de domaine. D’autres événements sont enregistrés pour les échecs d’inscription des enregistrements « A » et PTR de l’hôte. Vérifiez ces échecs dans les journaux des événements système sur les serveurs DNS et tous les autres ordinateurs affectés. Le client qui inscrit ces enregistrements peut enregistrer ces événements, ou les serveurs DHCP qui inscrivent les enregistrements pour le compte du client peuvent les enregistrer. Ces événements supplémentaires peuvent fournir des informations sur la cause de l’échec.

La conversion d’un bail dynamique actif en réservation supprime les enregistrements « A » et PTR pour ce client

Ce comportement est inhérent au produit. Les enregistrements DNS (« A » ou PTR) sont automatiquement mis à jour lors de la demande de renouvellement DHCP suivante du client.

Éviter d’inscrire des cartes réseau indésirables dans DNS

Si une carte réseau est configurée pour inscrire l’adresse de connexion dans DNS, les services clients DHCP/DNS inscrivent l’enregistrement dans DNS. Si un ordinateur dispose d’une carte réseau que vous ne souhaitez pas inscrire, procédez comme suit :

  1. Dans Connections réseau, ouvrez les propriétés de la carte réseau indésirable, ouvrez propriétés TCP/IP, sélectionnez DNS avancé>, puis décochez la case Inscrire cette adresse de connexion dans DNS.
  2. Dans le volet gauche, ouvrez la console du serveur DNS, mettez en surbrillance le serveur, puis sélectionnezPropriétésde l’action>.
  3. Sous l’onglet Interfaces , sélectionnez Écouter uniquement sur les adresses IP suivantes. Supprimez l’adresse IP indésirable de la liste.
  4. Dans la page Propriétés de la zone , sélectionnez l’onglet Serveur de noms . Outre le nom de domaine complet du contrôleur de domaine, cet onglet répertorie l’adresse IP associée au contrôleur de domaine. Supprimez l’adresse IP indésirable si elle est répertoriée.
  5. Supprimez l’enregistrement « A » de l’hôte indésirable existant du contrôleur de domaine.

Délais de réponse aux requêtes DNS

Une requête de requête DNS peut expirer si le serveur DNS transfère la requête à des redirecteurs inaccessibles ou à des indicateurs racine. Pour résoudre ce problème, procédez comme suit :

  1. Ouvrez la console DNS sur le serveur DNS et case activée si les redirecteurs ou les redirecteurs conditionnels sont accessibles. Si l’un des redirecteurs est inaccessible, supprimez-les.
  2. Si le serveur DNS n’a pas besoin d’utiliser des redirecteurs et des indicateurs de racine, ouvrez la console DNS sur le serveur DNS, ouvrez la fenêtre Propriétés du serveur, sélectionnez Avancé, puis activez Désactiver la récursivité. (Ce paramètre désactive également les redirecteurs.)

ID d’événement 4004 et ID d’événement 4013

Message d’événement :

Le serveur DNS n’a pas pu ouvrir Active Directory. Ce serveur DNS est configuré pour utiliser les informations du service d’annuaire et ne peut pas fonctionner sans accès à l’annuaire. Le serveur DNS attend que le répertoire démarre. Si le serveur DNS est démarré mais que l’événement approprié n’a pas été journalisé, le serveur DNS attend toujours que le répertoire démarre.

Pour résoudre ce problème, consultez Résoudre les problèmes liés aux services AD DS et redémarrer le service serveur DNS.

La stratégie d’emplacement géographique du serveur DNS ne fonctionne pas comme prévu

Prenons l’exemple du scénario suivant :

  • Vous utilisez une zone intégrée à Active Directory (étendue de zone par défaut) nommée « contoso.com ».
  • Vous utilisez des étendues de zone de géolocalisation associées à des sous-réseaux spécifiques.
  • Vous utilisez l’applet de commande Windows PowerShell Add-DnsServerQueryResolutionPolicy pour configurer des stratégies de résolution DNS.

Dans ce scénario, le résultat souhaité est qu’un client tente de localiser une ressource demandée, d’abord dans l’étendue de la zone locale, puis dans l’étendue de la zone par défaut. Toutefois, une fois que le organization a configuré ces stratégies, les clients des sous-réseaux définis ne peuvent pas résoudre correctement les enregistrements hébergés dans l’étendue de zone par défaut (contoso.com). Par exemple, les clients ne peuvent pas résoudre hostA.contoso.com. Lorsque le serveur DNS reçoit ces demandes, il retourne un message « Échec du serveur ».

Pour résoudre ce problème, consultez La stratégie de géolocalisation du serveur DNS ne fonctionne pas comme prévu.

La résolution de noms DNS transférée échoue pour les requêtes double empilées

Vous utilisez une solution de serveur DNS tierce et vous ne pouvez pas résoudre les noms de manière cohérente lorsque vous utilisez le transfert conditionnel.

Le serveur DNS local (10.100.100.70) peut se connecter au serveur DNS configuré en tant que redirecteur conditionnel (10.133.3.250). La première requête du serveur DNS au redirecteur conditionnel résout correctement un nom (par exemple, nbob1.contoso.com). Après un certain temps, la résolution de noms cesse de fonctionner. Une requête nslookup vers le redirecteur conditionnel retourne un message d’erreur « domaine inexistant ».

Si vous effacez le cache du serveur DNS sur l’ordinateur de transfert (le serveur DNS local), la résolution de noms reprend. Toutefois, ce correctif est temporaire.

Pour résoudre ce problème, consultez Échec de la résolution de noms DNS transféré pour les requêtes double empilées.

Le serveur DNS perd sa configuration d’association de cartes réseau

Prenons l’exemple du scénario suivant :

  • L’ordinateur serveur DNS dispose de plusieurs cartes réseau que vous utilisez dans une configuration d’association de cartes réseau.
  • Vous configurez le serveur DNS pour écouter l’adresse IP de la carte réseau d’association.
  • Sous l’onglet Interfaces de la boîte de dialogue Propriétés du serveur DNS du Gestionnaire DNS, vous pouvez configurer l’adresse IP que vous souhaitez utiliser.

Après avoir redémarré le serveur DNS, Windows supprime le paramètre. Le serveur DNS recommence à écouter toutes les adresses IP.

Lorsque cette modification se produit, Windows consigne l’ID d’événement 410 dans le journal des événements du serveur DNS :

La liste des interfaces restreintes des serveurs DNS ne contient pas d’adresse IP valide pour l’ordinateur serveur. Le serveur DNS utilise toutes les interfaces IP sur l’ordinateur. Utilisez la boîte de dialogue interfaces et propriétés du serveur du gestionnaire DNS pour vérifier et réinitialiser les adresses IP que le serveur DNS doit écouter. Pour plus d’informations, consultez « Pour restreindre l’écoute d’un serveur DNS uniquement sur les adresses sélectionnées » dans l’aide en ligne.

Pour résoudre ce problème, consultez Serveur DNS revenir à l’écoute sur toutes les adresses IP au lieu de l’adresse IP d’association de cartes réseau configurée.

Comportement d’inscription d’enregistrement DNS si le serveur DHCP gère les mises à jour DNS dynamiques

Vous disposez d’une infrastructure qui utilise des clients DHCP (Dynamic Host Configuration Protocol) Windows et des serveurs Microsoft DHCP pour attribuer et gérer des adresses IP. Sur le serveur DHCP, sélectionnez Activer les mises à jour dynamiques DNS en fonction des paramètres ci-dessous et Toujours mettre à jour dynamiquement les enregistrements DNS. Dans cette configuration, vous vous attendez à ce que le serveur DHCP gère les mises à jour DNS dynamiques pour les enregistrements « A » et « PTR ». Toutefois, vous constatez que le client et le serveur créent des enregistrements DNS. Selon votre configuration, ce comportement a les effets suivants :

  • Si vous configurez les zones DNS pour les mises à jour dynamiques non sécurisées et sécurisées , vous voyez que le serveur DHCP crée des enregistrements, puis que le client DHCP supprime et recrée les mêmes enregistrements.
  • Si vous configurez les zones DNS pour sécuriser uniquement les mises à jour dynamiques, les enregistrements DNS peuvent devenir incohérents. Le serveur DHCP et le client DHCP créent des enregistrements. Toutefois, le serveur DHCP ne peut pas mettre à jour les enregistrements créés par le client DHCP, et le client DHCP ne peut pas mettre à jour les enregistrements créés par le serveur DHCP.

Pour résoudre ce problème, consultez Comportement d’inscription des enregistrements DNS lorsque le serveur DHCP est défini sur « Toujours mettre à jour dynamiquement les enregistrements DNS ».

Collecte de données

Avant de contacter Support Microsoft, vous pouvez collecter des informations sur votre problème.

Configuration requise

  • Exécutez TSS dans le contexte de sécurité d’un compte disposant de privilèges d’administrateur sur le système local. La première fois que vous exécutez TSS, acceptez le CLUF. (Une fois que vous avez accepté le CLUF, TSS ne vous invite plus.)
  • Nous vous recommandons d’utiliser la stratégie RemoteSigned d’exécution PowerShell, au niveau de l’étendue LocalMachine .

Remarque

Si la stratégie d’exécution PowerShell actuelle n’autorise pas l’exécution de TSS, effectuez les actions suivantes :

  1. Définissez la RemoteSigned stratégie d’exécution pour le niveau de processus en exécutant l’applet de commande , Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  2. Pour vérifier que la modification prend effet, exécutez l’applet de Get-ExecutionPolicy -List commande .

Ces autorisations au niveau du processus s’appliquent uniquement à la session PowerShell actuelle. Une fois que vous avez fermé la fenêtre PowerShell dans laquelle TSS s’exécute, l’autorisation affectée pour le niveau de processus revient à l’état précédemment configuré.

Collecter les informations clés avant de contacter le support Microsoft

  1. Téléchargez TSS sur tous les nœuds et développez le fichier dans le dossier C :\tss .

  2. Ouvrez le dossier C :\tss dans une fenêtre d’invite de commandes PowerShell avec élévation de privilèges.

  3. Démarrez les traces sur le client et le serveur en exécutant les applets de commande suivantes :

    • Client:

      TSS.ps1 -Scenario NET_DNScli
      
    • Serveur:

      TSS.ps1 -Scenario NET_DNSsrv
      
  4. Acceptez le CLUF si les traces sont exécutées pour la première fois sur le serveur ou le client.

  5. Autoriser l’enregistrement (PSR ou vidéo).

    Remarque

    Si vous collectez des journaux sur le client et le serveur, attendez que ce message apparaisse sur les deux nœuds avant de reproduire le problème.

  6. Reproduisez le problème.

  7. Après avoir reproduit le problème, entrez Y pour terminer la journalisation des données.

TSS stocke les traces dans un fichier compressé dans le dossier C :\MS_DATA . Vous pouvez charger le fichier dans l’espace de travail à des fins d’analyse.

References