Boîte à Outils Informatique
Procédure

Résoudre un problème de DNS sous Windows

Diagnostiquer la résolution DNS Windows en séparant configuration IP, serveur DNS, suffixes, cache, enregistrement précis et chemin réseau, avec Resolve-DnsName, nslookup et trace si nécessaire.

Réseau
ThématiqueRéseau informatique →
⌚ Environ 6 min de lecture
Voir mes favoris
DomaineRéseauNiveauIntermédiaireDurée20-90 minRisqueFaible

Objectif

Identifier pourquoi un client Windows ne résout pas un nom ou obtient une mauvaise réponse DNS, en vérifiant d’abord sa configuration et son serveur DNS, puis le cache, les suffixes, le type d’enregistrement et la connectivité avant d’escalader vers le serveur DNS.

Prérequis

  • Nom exact qui échoue et réponse attendue.
  • Adresse des DNS que le poste doit utiliser selon le réseau/VPN
  • Une requête interne et une requête publique de référence.
  • Accès au poste et, si nécessaire, au serveur DNS.
  • Heure précise du problème si une capture doit être réalisée.

Procédure pas à pas

1

Vérifier la configuration IP et les serveurs DNS

Commencez par ipconfig /all. Contrôlez adresse, masque, passerelle, serveurs DNS et suffixe de connexion. Sur un client de domaine, les serveurs DNS doivent généralement être ceux qui savent résoudre les zones AD internes. Si l’adresse ou les DNS viennent de DHCP, notez le serveur DHCP et l’heure du bail.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select InterfaceAlias,ConnectionSpecificSuffix,RegisterThisConnectionsAddress
Résultat attendu
  • Le poste utilise les DNS et suffixes attendus pour son réseau.
2

Tester directement le nom défaillant

Utilisez Resolve-DnsName et nslookup pour le FQDN exact. Ajoutez un point final au nom si vous voulez éviter que Windows ajoute des suffixes de recherche. Relevez le type de réponse, TTL, serveur et éventuel NXDOMAIN/SERVFAIL. Testez aussi le type A, AAAA, CNAME ou SRV réellement attendu.

Resolve-DnsName '<FQDN>.' -DnsOnly
nslookup <FQDN>.
Resolve-DnsName '<FQDN>.' -Type A
Résultat attendu
  • Le code/résultat DNS réel du nom défaillant est connu.
3

Interroger chaque serveur DNS explicitement

Si plusieurs DNS sont configurés, interrogez-les séparément. Une différence de réponse peut indiquer une réplication, un forwarder ou un serveur secondaire incohérent. Ne concluez pas que « le DNS marche » parce qu’un seul serveur répond. Pour un problème intermittent, répétez plusieurs fois la requête vers chaque serveur.

Resolve-DnsName '<FQDN>.' -Server <DNS-IP-1> -DnsOnly
Resolve-DnsName '<FQDN>.' -Server <DNS-IP-2> -DnsOnly
nslookup <FQDN>. <DNS-IP-1>
Résultat attendu
  • Chaque DNS configuré renvoie une réponse cohérente ou le serveur défaillant est identifié.
4

Comparer nom court et FQDN

Si le FQDN fonctionne mais pas le nom court, inspectez le suffixe DNS de connexion et la liste de recherche. Le problème est alors souvent lié à la qualification du nom plutôt qu’au serveur. Sur un VPN, une NRPT ou un suffixe spécifique peut changer le comportement. Utilisez Get-DnsClient et les politiques NRPT si elles existent.

Resolve-DnsName '<SHORTNAME>'
Resolve-DnsName '<FQDN>.'
Get-DnsClientNrptPolicy -ErrorAction SilentlyContinue
Résultat attendu
  • Le mécanisme de suffixe ou NRPT est confirmé ou écarté.
5

Inspecter puis vider le cache client

Affichez le cache avant de le vider afin de voir si une réponse négative ou ancienne est présente. Microsoft recommande ipconfig /displaydns puis /flushdns dans le diagnostic client. Après vidage, refaites la même requête. Si la mauvaise réponse revient immédiatement, le problème est en amont.

ipconfig /displaydns
ipconfig /flushdns
Clear-DnsClientCache
Resolve-DnsName '<FQDN>.' -DnsOnly
Résultat attendu
  • Le test distingue un cache local obsolète d’une mauvaise réponse serveur.
6

Vérifier la connectivité vers le DNS

Confirmez que le client atteint l’adresse du serveur DNS par le réseau prévu. Un ping peut être bloqué par firewall et n’est donc pas une preuve absolue. Utilisez une requête DNS explicite comme test principal ; Test-NetConnection sur TCP 53 peut compléter pour les scénarios où TCP est requis. Sur VPN, vérifiez la route vers le DNS interne.

ping <DNS-IP>
Test-NetConnection <DNS-IP> -Port 53
route print
Résultat attendu
  • Le chemin vers le serveur DNS est cohérent avec le réseau ou le VPN utilisé.
7

Mesurer les délais de résolution

Un DNS peut répondre mais trop lentement. Mesurez plusieurs requêtes vers le même serveur. Microsoft indique qu’une résolution inférieure à une seconde est généralement acceptable dans son guide client, mais comparez surtout avec votre référence interne. Une latence élevée peut venir d’un forwarder, d’une perte réseau ou d’un serveur surchargé.

(Measure-Command {Resolve-DnsName -Name '<FQDN>' -Server <DNS-IP> -DnsOnly}).TotalMilliseconds
Résultat attendu
  • Le problème est classé erreur de résolution ou simple latence excessive.
8

Contrôler hosts, proxy DNS et applications

Vérifiez le fichier hosts seulement si la réponse Windows diffère de nslookup/Resolve-DnsName ou si une application résout autrement. Certains VPN, agents de sécurité et navigateurs peuvent utiliser leur propre mécanisme de résolution ou DoH. N’ajoutez pas une entrée hosts comme correction permanente d’un enregistrement DNS interne erroné.

Get-Content C:WindowsSystem32driversetchosts
Resolve-DnsName '<FQDN>.'
Résultat attendu
  • Aucune surcharge locale ne remplace involontairement la réponse DNS attendue.
9

Capturer le trafic si l’échec reste intermittent

Pour un incident non reproductible en continu, démarrez une trace réseau Windows, videz le cache, reproduisez une seule fois puis arrêtez la capture. Microsoft recommande cette collecte côté client et serveur DNS pour les cas complexes. Conservez le fichier ETL avec l’heure et le nom testé.

netsh trace start capture=yes tracefile=C:Tempdns-client.etl
ipconfig /flushdns
nslookup <FQDN>.
netsh trace stop
Résultat attendu
  • Une capture contient la requête et la réponse correspondant à l’échec.

Validation

La procédure est validée lorsque :

  • Le client utilise les serveurs DNS et suffixes prévus.
  • Le nom interne et une référence publique se résolvent correctement.
  • Les différents DNS configurés renvoient des réponses cohérentes.
  • Le cache, le VPN/NRPT et la connectivité ont été testés séparément.

Retour arrière

  • Restaurer les adresses DNS précédentes si un test les a modifiées.
  • Supprimer toute entrée hosts temporaire créée pour le diagnostic.
  • Remettre les paramètres VPN/NRPT d’origine si un test ciblé les a changés.
  • Ne conservez pas un DNS public sur un poste de domaine comme workaround permanent.

Dépannage / erreurs fréquentes

  • FQDN fonctionne mais nom court échoue : vérifier suffixe de connexion et search list.
  • Un DNS répond correctement et l’autre non : traiter réplication/zone/forwarder sur le serveur défaillant.
  • NXDOMAIN revient après flushdns : la réponse vient du DNS en amont, pas du cache client.
  • DNS fonctionne hors VPN mais pas connecté : vérifier NRPT, routes et DNS poussés par le VPN.
  • Résolution lente avec réponse correcte : mesurer le temps vers chaque DNS et analyser forwarders/réseau.

Références officielles

♡ 0