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

Sur mon poste de travail Windows XP, je peux trouver la machine à laquelle je souhaite me connecter dans DNS avec nslookup:

nslookup wolfman
Server: dns.company.com
Address: 192.168.1.38

Name: wolfman.company.com
Address: 192.168.1.178

Mais, lorsque j'essaie de me connecter à cette machine, un message d'erreur me dit que la machine est introuvable (c'est-à-dire qu'elle ne peut pas être recherchée dans le DNS):

C:\> ping wolfman
Ping request could not find host wolfman. Please check the name and try again.

Je peux me connecter si j'utilise l'adresse IP directement:

C:\> ping 192.168.1.178

Pinging 192.168.1.178 with 32 bytes of data:

Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=44ms TTL=126
Reply from 192.168.1.178: bytes=32 time=38ms TTL=126

Je pourrais contourner ce problème en ajoutant une entrée à mon hostsfichier, mais je préférerais savoir pourquoi cela se produit. Le problème est passager, je peux très bien me connecter à la machine la majeure partie de la journée.

Comment est-ce possible?

ETA: J'ai omis ceci par souci de brièveté, mais il a été demandé:

C:\> ping wolfman.company.com
Ping request could not find host wolfman.company.com. Please check the name and try again.

ETA: D'autres applications obtiennent les mêmes résultats. J'ai seulement essayé de ping pour simplifier. telnet ne peut pas se connecter, les applications Cygwin affichent un message "hôte inconnu".

Mise à jour: à l'aide de Wireshark, j'ai constaté que mon poste de travail n'essayait pas une recherche DNS. Il s'agit simplement de signaler le message d'erreur "impossible de trouver l'hôte".

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

Certaines commandes qui réinitialiseront divers états du réseau:

Réinitialiser les entrées WINSOCK sur les valeurs d'installation par défaut: netsh winsock reset catalog
Réinitialiser la pile TCP / IP sur les valeurs d'installation: netsh int ip reset reset.log
Vider le cache de résolution DNS: ipconfig /flushdns
Renouveler l'enregistrement du client DNS et actualiser les baux DHCP: ipconfig /registerdns
Vider la table de routage: route /f (redémarrage requis)

Essayez de faire un ping avec nom d’hôte suivi d’un point. Donc au lieu d' ping wolfmanutiliserping wolfman.

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

Essayez de ipconfig /displaydnschercher Wolfman. S'il est mis en cache en tant que "nom n'existe pas" (peut-être à cause d'une recherche échouée par le passé), vous pouvez vider le cache avec ipconfig /flushdns.

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

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

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 suffixes DNS (dans l'ordre)
7. Ajouter .comme suffixe.

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

Cela devrait faire le ping wolfmantravail.

Explication

nslookup wolfman(nom du 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 nslookupcommande. Cela fonctionne déjà, nous avons donc vérifié que le DNS fonctionne et que cela wolfmancorrespond bien à une adresse IP.

En revanche, il ping wolfmanfaut faire deux choses:

1. Obtenez l'adresse IP à laquelle correspond le nom d'hôte ( wolfman).
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. Par souci de compatibilité avec les versions antérieures, Windows prend en charge diverses méthodes de résolution du nom d’hôte (fichier hosts, DNS, NetBIOS / WINS, fichier LMHOST).

Malheureusement, il semble que la pingcommande 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 à effectuer une recherche DNS en utilisant un nom de domaine complet ( FQDN ). Dans la pratique, nous faisons cela en suffixant un .point au nom d' hôte: wolfman.. Essayez de ping wolfman.vérifier que cela fonctionne.

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

nslookup fonctionne différemment des autres commandes lors de la résolution de noms / adresses IP sous Windows.

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

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

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

J'ai eu du mal avec un problème similaire et j'ai essayé la solution proposée par @harrymc. J'ai trouvé ce qui semble finalement (au moins un peu) fonctionner sur le forum Microsoft Technet ( nslookup fonctionne mais rien d'autre ne dispose de DNS sur un ordinateur autonome Win7 ).

Voici la citation:

... essayez d'utiliser la commande ci-dessous pour vider et réinitialiser un cache de résolution 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, fondamentalement, ce qui me manquait était ipconfig /registerdns

Aujourd'hui, nous avions le même problème , mais la solution était différente . Alors je me suis dit que je l’ajouterais pour référence car c’était le premier résultat de recherche.

• Problème : pingne résoudra pas un nom d’hôte, mais nslookuppourra. (Observé sur 2 hôtes Windows Server 2012 R2 différents.)
• Cause : (pour chaque hôte) Plusieurs cartes réseau sont connectées à l'hôte et plusieurs passerelles par défaut sont configurées.
• Solution : (pour chaque hôte) Supprimez la passerelle par défaut de la configuration de toutes les cartes réseau, à l'exception d'une, afin de ne conserver 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 à DNS, tandis que ping et d'autres outils recherchent tout d'abord dans le fichier "hôtes", 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 ne le résoudrait:
- Le ping du nom complet qualifié a fonctionné.
- Ping le nom non qualifié n'a pas.
- Tous deux travaillaient sur plusieurs autres systèmes, dotés du même système d'exploitation et apparemment de la même configuration.
- Toutes les chaînes de recherche de suffixe nécessaires étaient là.
(Notez que certains des correctifs proposés, tels que la solution de contournement pour les requêtes multi-libellées, ne sont évidemment pas pertinents, car le nom non qualifié ne comporte qu'une partie.)

Ensuite, j'ai remarqué que le système cible sur lequel je tentais de faire un ping n'avait PAS d'adresse IPv6. J'ai donc essayé "ping -4 nom_qualifié " et le bingo! cela a fonctionné.
Donc, pour une raison quelconque, sur ce système uniquement, ping a uniquement tenté de résoudre un nom non qualifié-> adresse IPv6, et non un nom non qualifié-> IPv4.
Pour moi, le correctif consistait à désactiver IPv6 complètement car je n'en ai absolument pas besoin. Mais je serais vraiment intéressé de trouver un moyen plus doux de dire à ping (ou probablement au service client DNS) d'essayer de résoudre les adresses IPv4 et IPv6.

L'ajout d'une entrée dans le fichier c:/windows/system32/drivers/etc/hostspeut le réparer.

J'essayais de comprendre pourquoi je pouvais utiliser un ordinateur gagnant 7 ping serverqui fonctionnait et l'autre qu'il ne pouvait pas résoudre server. Cependant, les deux pouvaient faire un ping server.lanque je n'avais pas bien compris.

Il s'avère que j'avais modifié certains paramètres (suffixes DNS) pour ne pas avoir à utiliser les noms de domaine complets lors de l'utilisation du réseau privé professionnel. Je devais ajouter mon .lansuffixe local à ces suffixes pour que les deux ordinateurs fonctionnent de la même manière.

Allez au Panneau de configuration> Réseau et Internet> Connexions réseau, cliquez avec le bouton droit de la souris 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. Ensuite, le bouton Avancé ... dans cette nouvelle fenêtre. Allez sur l'onglet DNS, c'est là que j'avais ajouté un suffixe DNS pour mon travail mais j'avais également besoin d'un suffixe pour mes connexions domestiques normales.

Je suis tombé sur ce problème aussi. Le moyen le plus "facile" de le résoudre pour moi était simplement d'ajouter un .à la fin du nom d'hôte. Cependant, c'est plutôt agaçant. La plupart des réseaux n'en ont pas besoin. Je préférerais ne pas avoir à dire à tous les autres membres du réseau de le faire s'ils ont besoin d'accéder à la même ressource.

J'examinais la suggestion de Frederik Aalund en tant que solution possible et remarquai qu'ils suggéraient de passer de l'option par défaut "Ajouter les suffixes DNS principaux et spécifiques à la connexion". Cela m'a fait penser que mon réseau était peut-être un peu mal configuré.

En regardant mes paramètres DD-WRT, le "domaine LAN" n'a pas été défini. Définir ce paramètre sur une chaîne arbitraire semble avoir résolu ce problème pour tous les clients de mon réseau sans configuration particulière sur chaque ordinateur, solution que je recherchais! :)

J'ai rencontré ce problème lorsque nous avons migré de Windows XP vers Windows 7, le problème était lié à un problème de requête DNS multiple de Windows 7.

Autoriser l'ajout de suffixe DNS à des requêtes de noms multi-étiquettes non qualifiées - voir:

http://computerstepbystep.com/allow_dns_suffix_appending_to_unqualified_multi_label_name_queries.html

J'espère que cela t'aides

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

Vider le cache

sudo killall -HUP mDNSResponder
sudo dscacheutil -flushcache

Je soulève cette question parce que cela m'a dérangé l'année dernière et j'ai peut-être trouvé une solution de contournement.

Pour moi, il semblerait que certains systèmes DNS-caching du client Windows soient défectueux. Windows 7 et 8.1 en sont affectés… ne peut plus en dire long sur Windows XP. ping ne résout pas le nom. ce n'est pas la partie icmp qui est importante mais la partie résolvant le nom). nslookup est conçu pour interroger le serveur de noms et fait exactement cela, sans aucune résolution de noms-hiérarchies Windows.

Le redémarrage du service dnscache a aidé à chaque fois. Mais depuis que j'ai désactivé IPv6 sur toutes les interfaces client, le problème ne s'est plus posé.

À votre santé!

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

En tant que tarif, je peux me rappeler que PING utilise Netbios / WINS et DNS (dans cet ordre, du moins si vous ne spécifiez pas de nom de domaine complet).

WINS a disparu il y a plusieurs années, mais Netbios est peut-être toujours activé sur votre interface. PING peut donc utiliser des netbios qui risquent de ne générer aucun résultat. Surtout si le trafic passe par un routeur quelque part.

Il suffit de désactiver Netbios pour que Ping utilise DNS en priorité et ajoute le nom DNS Surffic enregistré sur l'interface à votre nom d'hôte.

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

En gros, si votre fichier hosts contient des entrées identiques à l’IP que votre ping tente de résoudre, il échouera.

Par exemple, si dans votre DNS, vous avez un enregistrement pour www.example.com - 10.0.0.20, mais que vous avez une entrée dans le fichier hosts de votre client, 10.0.0.20 quelque chose de différent, vous ne pourrez pas faire un ping sur le site www. .exemple.com

Étrange hein

Dans mon cas, ce problème a été résolu en ajoutant le domaine de l'hôte que j'essayais d'envoyer à une option de stratégie de groupe nommée "Liste de recherche de suffixe DNS" .

La procédure en bref est la suivante: Ouvrez gpedit.mscet accédez à Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, définissez-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

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

A changé d'adresse IP en DHCP et tout fonctionnait bien.

Aucune des solutions ici ne fonctionnait pour moi. Ce qui a fonctionné pour moi a été de me reconnecter au vpn de mon travail en utilisant OpenVPN. Puis, après avoir déconnecté, tout a continué à fonctionner.

Je pense que le problème était lié à la coupure de courant lorsque mon ordinateur était connecté à openVPN. La seule façon pour moi de comprendre cela était d'utiliser WireShark. J'ai remarqué que les IP de destination pour toutes les requêtes allaient aux IP sur le réseau interne de mon travail.

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 d'empêcher les attaques ou l'analyse de base du réseau. J'ai constaté que de nombreux routeurs que vous achetez sont livrés avec un paramètre permettant de désactiver le ping et les utilitaires similaires activés par défaut.

vous pouvez trouver plus sur ICMP ici:

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol