Waarom is 'ping' niet in staat om een naam op te lossen als 'nslookup' goed werkt?

Ik geloof dat nslookup een winsoklverbinding opent op de DNS-poort en een zoekopdracht geeft, terwijl ping gebruik maakt van de DNS-clientdienst. Je zou kunnen proberen deze service te stoppen en zien of dit een verschil maakt.

Enkele commando’s die verschillende netwerk statussen zullen herinitialiseren :

Reset WINSOCK items naar installatie standaardinstellingen : netsh winsock reset catalog Reset TCP/IP stack naar installatie standaardinstellingen : netsh int ip reset reset.log Flush DNS resolver cache : ipconfig /flushdns Vernieuwen van DNS client registratie en verversen van DHCP leases : ipconfig /registerdns Flush routing tabel : route /f (herstarten noodzakelijk)

Probeer te pingen met de hostnaam gevolgd door een punt. Dus in plaats van ping wolfman gebruik je ping wolfman.

die je zou moeten laten oplossen zonder dat je workarounds hoeft te doen met hosts file, etc.

Probeer ipconfig /displaydns en zoek wolfman. Als het in de cache staat als “naam bestaat niet” (mogelijk vanwege een eerdere intermitterende mislukte lookup), kun je de cache doorspoelen met ipconfig /flushdns.

nslookup gebruikt de cache niet, maar ondervraagt de DNS-server direct.

Probeer . toe te voegen aan de DNS suffixen voor die verbinding. Ga dus naar:

1. 1. Ethernet status
2. 2. Klik op Eigenschappen
3. 4. Internet Protocol Versie 4
4. Klik op Eigenschappen
5. Klik op Eigenschappen
6. Klik op Eigenschappen
7. 4. Klik op Eigenschappen
8. Klik op Geavanceerd
9. Klik op Eigenschappen . Voeg deze DNS suffices toe (in volgorde)
10. Voeg . toe als suffix.

Dezelfde stappen worden geïllustreerd in de volgende screenshot:

Dit zou ping wolfman moeten laten werken.

Uitleg

nslookup wolfman (name server lookup: wolfman) stuurt de hostnaam (wolfman) naar de DNS (domeinnaam systeem) om het corresponderende IP adres te verkrijgen. Dit is het enige doel van het nslookup commando. Dit werkt al, dus we hebben geverifieerd dat het DNS werkt en dat wolfman inderdaad overeenkomt met een IP adres.

daarentegen moet ping wolfman twee dingen doen:

1. Krijg het IP waar de hostnaam (wolfman) mee correspondeert.
2. 1. Stuur pakketten naar het IP en luister naar het antwoord

3. Op Windows (zelfs recente versies zoals Windows 10) kan de eerste stap gemakkelijk mislukken. Omwille van de achterwaartse compatibiliteit ondersteunt Windows verschillende methoden voor het oplossen van hostnamen (hosts file, DNS, NetBIOS/WINS, LMHOST file).

Helaas lijkt het erop dat Windows’ ping commando niet altijd een DNS lookup probeert. Ik ken de specifieke omstandigheden die dit gedrag veroorzaken niet.

Gelukkig kunnen we Windows dwingen om een DNS lookup te doen door gebruik te maken van een FQDN (volledig gekwalificeerde domeinnaam). In de praktijk doen we dit door een . punt achter de hostnaam te zetten: wolfman.. Probeer ping wolfman. en controleer of het werkt.

De laatste stap is om Windows te dwingen dit punt zelf toe te voegen. Ik heb in het begin van dit antwoord al laten zien hoe dit moet.

nslookup werkt anders dan andere commando’s bij het oplossen van namen/ip-adressen op Windows.

De normale resolutiemethode op Windows is als volgt:

1. De client controleert of de gevraagde naam zijn eigen naam is.
2. 2. De client zoekt vervolgens een lokaal Hosts bestand, een lijst met IP-adressen en namen die zijn opgeslagen op de lokale computer.
3. De client controleert of de gevraagde naam zijn eigen naam is. 3. Domeinnaamsysteem (DNS) servers worden opgevraagd.
4. Als de naam nog steeds niet is opgelost, wordt de NetBIOS-naamresolutievolgorde gebruikt als back-up. Deze volgorde kan worden gewijzigd door het NetBIOS-knooppunttype van de client te configureren.

nslookup daarentegen wordt gebruikt voor het testen van Domeinnaamservers.

Ik heb geworsteld met een soortgelijk probleem en heb de oplossing geprobeerd die @harrymc heeft voorgesteld. Ik vond wat uiteindelijk lijkt te werken (althans enigszins) op het microsoft technet forum nslookup werkt maar niets anders heeft DNS op standalone Win7 PC )

Hier is het citaat:

… probeer het onderstaande commando te gebruiken om een client resolver cache door te spoelen en te resetten voor de test.

ipconfig /flushdns

ipconfig /registerdns

Raadpleeg de onderstaande link voor meer details. http://jefferyland.wordpress.com/2011/07/28/quick-review-of-flushdns-registerdns-and-dns-queries/

Dus in principe ontbrak het mij aan ipconfig /registerdns

Net vandaag hadden we hetzelfde probleem, maar de oplossing was anders. Dus ik dacht, ik voeg het toe ter referentie omdat dit het beste zoekresultaat is.

• Probleem : ping lost een hostnaam niet op, maar nslookup kan dat wel. (Waargenomen op 2 verschillende Windows Server 2012 R2 hosts.)
• Oorzaak : (Voor elke host) De host heeft meer dan één NIC aangesloten en er zijn meerdere standaard gateways geconfigureerd.
• Oplossing : (Voor elke host) Verwijder de standaardgateway uit de configuratie van alle NIC’s op één na, zodat er alleen één standaardgateway is geconfigureerd.

Misschien staat wolfman.company.com wel vermeld in C:\Windowssystem32 en zien de chauffeurs dat bestand over het hoofd en vragen altijd aan DNS, terwijl ping en andere tools eerst opzoeken in het “hosts” bestand, en dan in DNS.

Ik had hetzelfde probleem op een Windows 2012R2 (=8.1) systeem, en probeerde alle bovenstaande suggesties, maar geen van hen loste het op: - Pingen van de volledig gekwalificeerde naam werkte. - Pingen van de ongekwalificeerde naam werkte niet. - Beide werkten op verschillende andere systemen, die hetzelfde OS hadden en blijkbaar dezelfde configuratie.
- Alle benodigde suffix zoekstrings waren aanwezig. (Merk op dat sommige van de voorgestelde fixes, zoals de workaround voor de multi-label queries, duidelijk niet relevant zijn, omdat de ongekwalificeerde naam slechts een deel heeft)

Toen merkte ik dat het doelsysteem dat ik probeerde te pingen GEEN IPv6 adres had. Dus probeerde ik “ping -4 _ongekwalificeerde naam”, en bingo! dit werkte. Dus om een of andere reden, alleen op dit systeem, probeerde ping alleen ongekwalificeerde naam->IPv6 adres op te lossen, en niet ongekwalificeerde naam->IPv4. Voor mij was de oplossing om IPv6 volledig uit te schakelen, omdat ik het helemaal niet nodig heb. Maar ik zou echt geïnteresseerd zijn om een zachtere manier te vinden om ping (of vermoedelijk de DNS-clientservice) te vertellen om te proberen zowel IPv4- als IPv6-adressen op te lossen.

Ik probeerde uit te vinden waarom ik op de ene win 7 computer ping server kan gebruiken die werkt, en de andere kan het server niet oplossen. Maar beide konden ping server.lan wel, wat ik niet helemaal begreep.

blijkt dat ik geknoeid had met enkele instellingen (DNS suffixen) om geen FQDN’s te hoeven gebruiken tijdens het gebruik van het werk VPN. Ik moest mijn lokale .lan toevoegen aan die suffixen om beide computers hetzelfde te laten werken.

Ga naar Control Panel > Netwerk en Internet > Netwerkverbindingen en klik met de rechtermuisknop op je netwerkverbinding en druk op Eigenschappen. Klik op Internet Protocol versie 4 en klik op de knop Eigenschappen. Dan de knop Geavanceerd… in dit nieuwe venster. Ga naar de DNS tab, dit is waar ik een DNS suffix had toegevoegd voor mijn werk maar ook nodig had voor mijn normale thuisverbindingen.

Ik kwam dit onderwerp ook tegen. De “makkelijkste” manier om het voor mij te repareren was om simpelweg een . toe te voegen aan het einde van de hostnaam. Dit is echter nogal vervelend. De meeste netwerken hebben dit niet nodig. Ik zou liever niet iedereen op het netwerk hoeven te vertellen dat ze dit moeten doen als ze toegang moeten krijgen tot dezelfde bron.

Ik keek naar de suggestie van Frederik Aalund als mogelijke oplossing en merkte dat ze voorstelden om van de standaard “Append primary and connection specific DNS suffixes” optie over te stappen. Dit deed me denken dat mijn netwerk misschien gewoon een beetje verkeerd geconfigureerd was.

Als ik naar mijn DD-WRT instellingen kijk, werd de “LAN Domain” niet ingesteld. Door dat op een willekeurige string te zetten lijkt dit probleem voor alle clients op mijn netwerk opgelost te zijn zonder dat er een speciale configuratie op elke machine aanwezig was, de oplossing die ik wilde! :)

Ik pak dit op omdat het me het laatste jaar stoorde en misschien vond ik wel een workaround.

Voor mij leek het een of ander dns-caching-systeem binnen de windows client defect te zijn. Windows 7 en 8.1 worden hierdoor beïnvloed… kan niet veel meer zeggen over Windows XP. ping lost de naam niet op. het is niet het icmp-gedeelte dat belangrijk is maar het deel dat de naam oplost). nslookup is ontworpen om de nameserver te bevragen en doet precies dat en geen windows naam-hierarchie-oplossing.

Het herstarten van de dnscache service hielp altijd. Maar omdat ik ** IPv6** heb uitgeschakeld op alle client-interfaces kwam het probleem niet meer voor.

Cheers!

Het toevoegen van een vermelding in het bestand c:/windows/system32/drivers/etc/hosts kan dit verhelpen.

Ik ben dit tegengekomen toen we migreerden naar windows 7 vanuit windows XP, het probleem had te maken met een Windows 7 Multi Label DNS Query probleem.

Laat DNS Suffix toevoegen aan Unqualified Multi-Label Name Queries - zie: http://computerstepbystep.com/allow_dns_suffixappendingtounqualified_multi-multi-labelqueries.html

Hoop dat dit helpt.

Als op mac os x het een DNS Cache probleem kan zijn:

Dump de cache sudo killall -HUP mDNSResponder sudo dscacheutil -flushcache

Ik kan het mis hebben omdat het gebaseerd is op mijn lang vergeten NT4 ressource-kit dagen.

Als tarief kan ik me herinneren dat PING gebruik maakt van Netbios/WINS en DNS (in die volgorde, tenminste als je geen FQDN opgeeft).

WINS is al vele jaren geleden weg, maar je hebt misschien nog steeds Netbios ingeschakeld op je interface en PING zou daarom netbios kunnen gebruiken die je misschien geen enkel resultaat geeft. Vooral als er ergens verkeer langs een router gaat.

Schakel gewoon Netbios uit en Ping zal DNS als eerste prioriteit gebruiken en de geregistreerde DNS Surffic op de interface aan je hostnaam toevoegen.

Net had dit probleem op een Windows 7-client aangesloten op een domein bleek het onjuiste DirectAccess instellingen in het register te zijn.

Probeer de inhoud van de volgende sleutel te wissen:

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

en start dan de ‘DNS Cache’ dienst opnieuw op.

Als dat helpt, kijk dan onder Groepsbeleidsbeheerconsole voor twee beleidsregels genaamd ‘DirectAccess Client Settings’ en ‘DirectAccess Server Settings’. Controleer of deze correct zijn geconfigureerd of zelfs nodig zijn in uw scenario. Ze worden soms automatisch aangemaakt met bepaalde instellingen voor de rol Routing en Remote Access op een server en dit was de oorzaak van het probleem van onze kant. http://virot.eu/manually-remove-direct-access-from-a-client/

Ik had hetzelfde probleem en het blijkt dat een andere machine hetzelfde IP adres had, en dat veroorzaakte het.

Veranderde IP terug naar DHCP en alles werkte prima.

In mijn geval was de oplossing voor dit probleem het toevoegen van het domein van de host die ik probeerde te pingen aan een groepsbeleidsoptie genaamd “DNS Suffix Search List”.

De procedure in het kort is dit: Open gpedit.msc en navigeer naar Computer Configuration -> Administrative Templates -> Network -> DNS Client > DNS Suffix Search List, zet deze op “Enabled” en voeg de domeinnaam toe aan de lijst (de lijst is standaard leeg).

Een meer gedetailleerde beschrijving van deze stappen is te vinden hier

Geen van de oplossingen hier werkte voor mij. Wat wel voor mij werkte, was de verbinding met de vpn van mijn werk via OpenVPN. Na het verbreken van de verbinding bleef alles werken.

Ik geloof dat het probleem te maken had met het uitvallen van de stroom terwijl mijn computer verbonden was met OpenVPN. De enige manier waarop ik daar achter kwam was door WireShark te gebruiken. Het viel me op dat de destination IP’s voor alle vragen naar IP’s op het interne netwerk van mijn werk gingen.

Ik heb net dit probleem, en vond iets heel eigenaardigs, en slaagde erin om het te repareren Lol

In principe, als u enige vermeldingen in uw hosts bestand, die hetzelfde zijn als de IP uw ping probeert op te lossen aan, zal het mislukken.

Bijvoorbeeld, als u in uw DNS een record hebt voor www.example.com - 10.0.0.20, maar dan heeft u een vermelding in het hosts-bestand van uw klant, 10.0.0.20 somethingelse.com, dan zult u niet in staat zijn om www.example.com

te pingen.

ping maakt gebruik van het ICMP-protocol, met name het ‘Echo Request’ en ‘Echo Reply’.

veel netwerken schakelen ICMP-hulpprogramma’s uit om aanvallen of het elementaire scannen van het netwerk te voorkomen. Ik heb veel routers gevonden die je koopt met een instelling om ping uit te schakelen en die standaard zijn ingeschakeld.

kun je hier vinden: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol