Pourquoi le "ping" est-il incapable de résoudre un nom alors que "nslookup" fonctionne correctement ?

Je pense que nslookup ouvre une connexion winsock sur le port DNS et émet une requête, alors que ping utilise le service DNS Client. Vous pourriez essayer d'arrêter ce service et voir si cela fait une différence.

Quelques commandes qui réinitialisent divers états du réseau :

Reset WINSOCK entries to installation defaults : netsh winsock reset catalog Reset TCP/IP stack to installation defaults : netsh int ip reset reset.log Flush DNS resolver cache : ipconfig /flushdns Renew DNS client registration and refresh DHCP leases : ipconfig /registerdns Flush routing table : route /f (reboot required)

Essayez de faire un ping avec le nom d'hôte suivi d'un point. Au lieu de ping wolfman, utilisez ping wolfman.

. Cela devrait vous permettre de résoudre le problème sans avoir à faire de contournement avec le fichier hosts, etc.

Essayez ipconfig /displaydns et cherchez wolfman. S'il est mis en cache comme “nom n'existe pas” (peut-être à cause d'une précédente recherche intermittente qui a échoué), vous pouvez vider le cache avec ipconfig /flushdns.

nslookup n'utilise pas le cache, mais interroge plutôt directement le serveur DNS.

Essayez d'ajouter . aux suffixes DNS pour cette connexion. C'est-à-dire, allez à :

1. Statut Ethernet
2. Cliquez sur Propriétés
3. Protocole Internet Version 4
4. Cliquez sur Propriétés
5. Cliquez sur Avancé
6. Ajouter ces DNS suffisent (dans l'ordre)
7. Ajouter . comme suffixe.

Les mêmes étapes sont illustrées dans la capture d'écran suivante :

Cela devrait faire fonctionner ping wolfman.

Explication

nslookup wolfman (recherche sur le serveur de noms : wolfman) envoie le nom d'hôte (wolfman) au DNS (système de noms de domaine) pour obtenir l'adresse IP correspondante. C'est le seul but de la commande nslookup. Cela fonctionne déjà, nous avons donc vérifié que le DNS fonctionne et que wolfman correspond bien à une adresse IP.

En revanche, ping wolfman doit faire deux choses :

1. Obtenir l'adresse IP à laquelle le nom d'hôte (wolfman) correspond.
2. Envoyer des paquets à l'IP et écouter la réponse

Sous Windows (même les versions récentes telles que Windows 10), la première étape peut facilement échouer. Pour des raisons de rétrocompatibilité, Windows supporte différentes méthodes de résolution de noms d'hôtes (fichier hosts, DNS, NetBIOS/WINS, fichier LMHOST).

Malheureusement, il semble que la commande ping de Windows ne tente pas toujours une recherche DNS. Je ne connais pas les conditions spécifiques qui déclenchent ce comportement.

Heureusement, nous pouvons forcer Windows à faire une recherche DNS en utilisant un FQDN (nom de domaine complet). En pratique, nous le faisons en ajoutant un point . au nom d'hôte : wolfman.. Essayez ping wolfman. et vérifiez que cela fonctionne.

La dernière étape consiste à forcer Windows à ajouter ce point lui-même. J'ai déjà montré comment faire au début de cette réponse.

nslookup fonctionne différemment des autres commandes pour la résolution des noms et adresses IP sous Windows.

La méthode de résolution normale sous Windows est la suivante :

1. Le client vérifie si le nom recherché est le sien.
2. Le client recherche ensuite un fichier Hosts local, une liste d'adresses IP et de noms stockés sur l'ordinateur local.
3. Si le nom n'est toujours pas résolu, la séquence de résolution de nom NetBIOS est utilisée comme sauvegarde. Cet ordre peut être modifié en configurant le type de nœud NetBIOS du client.

nslookup d'autre part est utilisé pour tester les serveurs de noms de domaine.

J'ai été confronté à un problème similaire et j'ai essayé la solution proposée par @harrymc. J'ai trouvé ce qui semble finalement (au moins quelque peu) fonctionner sur le forum microsoft technet nslookup fonctionne mais rien d'autre n'a de DNS sur un PC Win7 autonome )

Voici la citation :

… essayez d'utiliser la commande ci-dessous pour vider et réinitialiser le cache d'un résolveur client pour le test.

ipconfig /flushdns

ipconfig /registerdns

Veuillez vous référer au lien ci-dessous pour plus de détails. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

Donc, en gros, ce qui me manquait, c'était ipconfig /registerdns

Aujourd'hui encore, nous avions le même problème, mais la solution était différente. J'ai donc pensé l'ajouter à titre de référence, car c'est le résultat le plus important de la recherche.

• Problème : ping ne résoudra pas un nom d'hôte, mais nslookup le peut. (Observé sur 2 hôtes différents de Windows Server 2012 R2.)
• Cause : (Pour chaque hôte) L'hôte a plus d'un NIC connecté et il y a multiples passerelles par défaut configurées.
• Solution : (Pour chaque hôte) Supprimer la passerelle par défaut de la configuration de toutes les cartes réseau sauf une, de sorte qu'il ne reste qu'une seule passerelle par défaut.

Peut-être que wolfman.company.com est listé dans C:\Windows\system32\drivers\etc\hosts ?

nslookup contourne ce fichier et demande toujours le DNS, tandis que ping et d'autres outils recherchent d'abord dans le fichier “hosts”, puis dans le DNS.

J'ai eu le même problème sur un système Windows 2012R2 (=8.1), et j'ai essayé toutes les suggestions ci-dessus, mais aucune d'entre elles n'a pu le résoudre : - Pinger le nom pleinement qualifié a fonctionné. - Pinger le nom non qualifié n'a pas fonctionné. - Les deux ont fonctionné sur plusieurs autres systèmes, qui avaient le même OS et apparemment la même configuration.
- Toutes les chaînes de recherche de suffixe nécessaires étaient présentes. (Notez que certaines des corrections proposées, comme la solution de contournement pour les requêtes multi-labels, ne sont évidemment pas pertinentes, car le nom non qualifié n'a qu'une partie).

Puis j'ai remarqué que le système cible que j'essayais de pinger n'avait PAS d'adresse IPv6. J'ai donc essayé “ping -4 nomnon qualifié_”, et bingo ! cela a fonctionné. Donc pour une raison quelconque, sur ce système seulement, le ping a seulement essayé de résoudre le nom non qualifié->l'adresse IPv6, et non le nom non qualifié->IPv4. Pour moi, la solution était de désactiver complètement l'IPv6 car je n'en ai pas du tout besoin. Mais je serais très intéressé de trouver une façon plus douce de dire au ping (ou probablement au service client DNS) d'essayer de résoudre les adresses IPv4 et IPv6.

J'essayais de comprendre pourquoi sur un ordinateur win 7 je peux utiliser ping server qui fonctionne, et sur l'autre il ne peut pas résoudre server. Cependant les deux pouvaient pinger server.lan ce que je n'ai pas bien compris.

Il s'avère que j'ai joué avec certains paramètres (suffixes DNS) pour ne pas avoir à utiliser les FQDN tout en utilisant le VPN de travail. J'ai dû ajouter mon .lan local à ces suffixes afin que les deux ordinateurs agissent de la même manière.

Allez dans le Panneau de configuration > Réseau et Internet > Connexions réseau et cliquez avec le bouton droit sur votre connexion réseau et cliquez sur Propriétés. Cliquez sur Internet Protocol Version 4 et cliquez sur le bouton Propriétés. Puis le bouton Avancé… dans cette nouvelle fenêtre. Allez à l'onglet DNS, c'est là que j'ai ajouté un suffixe DNS pour mon travail mais j'en avais aussi besoin pour mes connexions normales à la maison.

Je suis également tombé sur cette question. La façon la plus “simple” de le résoudre pour moi était d'ajouter simplement un . à la fin du nom d'hôte. Cependant, c'est assez ennuyeux. La plupart des réseaux n'exigent pas cela. Je préfère ne pas avoir à dire à tous les autres membres du réseau de le faire quand ils ont besoin d'accéder à la même ressource.

J'ai examiné la suggestion de Frederik Aalund comme solution possible et j'ai remarqué qu'ils ont suggéré de passer de l'option par défaut “Append primary and connection specific DNS suffixes”. Cela m'a fait penser que mon réseau était peut-être simplement légèrement mal configuré.

En regardant mes paramètres DD-WRT, le “LAN Domain” n'était pas configuré. Le fait de le définir sur une chaîne arbitraire semble avoir réglé ce problème pour tous les clients de mon réseau sans avoir de configuration spéciale sur chaque machine, la solution que je voulais ! :)

J'ai pris cette décision parce que cela m'a dérangé l'année dernière et j'ai peut-être trouvé une solution. Windows 7 et 8.1 sont touchés par cela… je ne peux plus dire grand chose sur Windows XP. ping ne résout pas le nom. ce n'est pas la partie icmp qui est importante mais la partie de résolution du nom). nslookup est conçu pour interroger le serveur de noms et fait exactement cela et pas de résolution de la hiérarchie des noms de Windows.

Le redémarrage du service dnscache m'a aidé à chaque fois. Mais depuis que j'ai désactivé l'IPv6 sur toutes les interfaces clients, le problème ne se pose plus.

Santé !

L'ajout d'une entrée dans le fichier c:/windows/system32/drivers/etc/hosts pourrait régler le problème.

J'ai rencontré ce problème lors de la migration de Windows XP vers Windows 7, il était lié à un problème de requête DNS multi-étiquettes sous Windows 7.

Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries - see : http://computerstepbystep.com/allow_dns_suffix_appending_to_unqualified_multi_label_name_queries.html

Espérons que cela vous aidera

Si sur mac os x, il pourrait s'agir d'un problème de cache DNS :

Dump the cache

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

Je me trompe peut-être parce que c'est basé sur mes jours de kit-ressource NT4, oubliés depuis longtemps.

Comme tarif, je me souviens que PING utilise Netbios/WINS et DNS (dans cet ordre, du moins si vous ne spécifiez pas de FQDN).

WINS a disparu depuis de nombreuses années, mais il se peut que Netbios soit encore activé sur votre interface et que PING utilise donc Netbios qui ne vous donnera peut-être aucun résultat. En particulier si le trafic passe par un routeur quelque part.

Désactivez simplement Netbios et PING utilisera le DNS en première priorité et ajoutera à votre nom d'hôte le Surffic DNS enregistré sur l'interface.

Ce problème est survenu sur un client Windows 7 connecté à un domaine et il s'est avéré que les paramètres DirectAccess du registre étaient incorrects.

Essayez d'effacer le contenu de la clé suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig

puis redémarrez le service “DNS Cache”.

Si cela vous aide, recherchez dans la console de gestion des politiques de groupe deux politiques appelées “DirectAccess Client Settings” et “DirectAccess Server Settings”. Vérifiez si elles sont configurées correctement ou même si elles sont nécessaires dans votre scénario. Elles sont parfois créées automatiquement avec certains paramètres pour le rôle de routage et d'accès à distance sur un serveur et c'est la cause du problème de notre part. http://virot.eu/manually-remove-direct-access-from-a-client/

J'ai eu le même problème et il s'est avéré qu'une autre machine avait la même adresse IP, et c'est ce qui en était la cause.

a changé l'IP pour revenir au DHCP et tout fonctionnait bien.

Dans mon cas, la solution à ce problème a été d'ajouter le domaine de l'hôte que j'essayais de pinger à une option de politique de groupe appelée “DNS Suffix Search List”.

Voici en bref la procédure à suivre : Ouvrez gpedit.msc et naviguez vers Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, mettez le sur “Activé” et ajoutez le nom de domaine à la liste (la liste est vide par défaut).

Une description plus détaillée de ces étapes peut être trouvée ici

Aucune des solutions proposées ici n'a fonctionné pour moi. Ce qui a fonctionné pour moi, c'est de me reconnecter au vpn de mon travail en utilisant OpenVPN. Ensuite, après avoir été déconnecté, tout a continué à fonctionner.

Je crois que le problème était lié à la coupure de courant pendant que mon ordinateur était connecté avec openVPN. La seule façon de résoudre ce problème était d'utiliser WireShark. J'ai remarqué que les IP de destination de toutes les requêtes allaient vers les IP du réseau interne de mon travail.

Je viens d'avoir ce problème, et j'ai trouvé quelque chose d'assez particulier, et j'ai réussi à le résoudre Lol

En gros, si vous avez des entrées dans votre fichier hosts, qui sont les mêmes que l'IP que votre ping essaie de résoudre, il échouera.

Par exemple, si dans votre DNS, vous avez un enregistrement pour www.example.com - 10.0.0.20, mais qu'ensuite vous avez une entrée dans le fichier hosts de votre client, 10.0.0.20 somethingelse.com, vous ne pourrez pas faire de ping sur www.example.com

Étrange hein

ping utilise le protocole ICMP, en particulier la “demande d'écho” et la “réponse d'écho”.

de nombreux réseaux désactivent les utilitaires ICMP afin de prévenir les attaques ou l'analyse de base du réseau. J'ai constaté que de nombreux routeurs que vous achetez sont dotés d'un paramètre permettant de désactiver le ping et que les utilitaires similaires sont activés par défaut.

vous pouvez en savoir plus sur ICMP ici : http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol