ping fails, nslookup works

[0528973]

Hallo,

bedankt dat je even komt kijken.
Ik zit hier met het volgende probleem:
Op een gegeven moment kunnen zowel mac, als windows(2K of XP) geen lokale websites meer bezoeken via hun browser, ze kunnen ze ook niet meer pingen. Echter ze kunnen ze nog wel resolven via nslookup of soortgelijke tools.

Lokale websites, zijn websites die op het intranet draaien. De windows en mac machines kunnen wel zonder problemen via nslookup de websites resolven, maar ze kunnen ze nog steeds niet pingen of bezoeken via hun browser. De enige client pc die nergens last van heeft is de linux machine.

Situatie:
1 Linux router,
1 Linux dhcp-, name- en winsserver(dhcpd, bind en samba),
10 clients waarvan 1 linux machine, 2 mac's en 7 windows machines(2K of XP)

Al de lokale websites staan vermeld met een wildcard in de dns configuratie bestanden en hier lijkt uiteindelijk dan ook niets mee mis te zijn. Het probleem doet zich op random tijden voor, soms tegelijkertijd op meerdere machines soms maar op 1 machine. Hier lijkt geen regelmaat in te ontdekken.

Ik ben niet bekend met netwerk troubleshooting en dus na een ochtend googlen, besloot ik maar om hier een topic te openen. Wat ik graag zou willen weten, in welke hoek moet ik dit probleem zoeken en hoe zou ik dit probleem eventueel kunnen oplossen.

Ondertussen heb ik uitgevonden dat:
het probleem lijkt opgelost te zijn, nadat men handmatig om een nieuw ip-adres vraagt aan de dhcp-server. Dit is natuurlijk geen werkbare oplossing.

Het lijkt geen dns of routing probleem te zijn, aangezien de intranet websites wel via nslookup geresolved worden en het feit dat iedereen nog gewoon externe websites kan bezoeken. Ik zal zo nog even de versienummers van bind, dhcpd en samba opzoeken en hier neerzetten.

Linux Distro: Debian testing
DHCPD versie: 2.0pl5-16.1
NAMED versie: 8.4.3-NOESW
SAMBA versie: 3.0.0-Debian

Alle machines bevinden zich in hetzelfde subnet en de instellingen van de netwerk kaarten in de windows machines na een dhcp request staan netjes op hybride, juiste nameservers, routers ed.

[ Voor 22% gewijzigd door 0528973 op 26-01-2004 11:54 ]

[0528973]

Is er dan niemand die dit leest of me kan helpen?

Nou ja, ik denk ondertussen al weer iets verder te zijn. Zou het kunnen liggen van de WINS-server van Samba eventueel? Windows werkt namelijk voor intranet zaken toch standaard met NETBIOS ed ipv een DNS server?

[Question Mark]

Wat is de uitkomst als je een ping probeert?

Is de reactie: "unknown host" dan is er een probleem met name-resolving
Is de reactie: "request timed out", dan is er een probleem met de verbinding

Hoe staat de name-resolution ingesteld op de clients (te zien met "ipconfig /all"). Staat deze op hybrid (eerst name-servers, daarna broadcast), of staat deze op broadcast (eerst broadcast proberen, daarna name-servers controleren)?

Overigens: Nslookup vraagt alleen een reverse query bij de nameserver. Dus van ip-adres naar dns-name. Nslookup zegt niets over de verbinding...

[ Voor 19% gewijzigd door Question Mark op 24-01-2004 09:40 ]

[0528973]

Question Mark,
Het maakt toch niet uit of het eerst nameserver proberen is en daarna pas broadcast of andersom? Het is iig hybrid ingesteld. Het punt van nslookup was ook meer dat de nameservers wel juist ingesteld staan en dus eigenlijk ook gewoon werken. Ping levert een unknown host op. Dit gebeurt echter niet direct na het opvragen van een ip-adres maar na een random tijd en op random client machines.

Het lijkt opgelost te worden via het een ipconfig /renew opdracht.

[0528973]

[subtiele kick ;)]
Is er hier dan niemand die me kan helpen hier...
[/subtiele kick ;)]

[Question Mark]

0528973 schreef op 24 januari 2004 @ 11:05:
Question Mark,
Ping levert een unknown host op. Dit gebeurt echter niet direct na het opvragen van een ip-adres maar na een random tijd en op random client machines.

Hmm. Het lijkt er dan toch op een name-resolving probleem. Dat de clients op hybrid staan is juist goed. Eerst name-servers daarna broadcast. Dat de clients na een bepaalde tijd het ip-adres niet meer weten komt doordat het geresolvde ip-adres na een bepaalde tijd uit de cache verdwijnen (deze tijd is configureerbaar via de registry). De clients hoort dan opnieuw het ip-adres bij de name-server op te vragen, maar dit gaat (soms) niet goed.

Staat het A-record (naam naar ip-adres) wel goed op de dns-servers? NSlookup gaat wel goed zeg je, maar dit test het PTR-record (ip-adres naar naam).

Wat staat er in de logfiles van de dns-servers?

[0528973]

Hey Question Mark,

Wederom bedankt voor het antwoord, een ander vermoeden begint steeds meer vorm te krijgen nu.

We hebben hier de situatue dat we een wildcard record hebben. Dit wildcard record wijst naar de server waar al onze intranet sites op staan. En de hostname van die machine kan dan nog wel omgezet worden als het misgaat met het opvragen van de intranet sites. Die hostname geeft namelijk wel netjes een PTR en A record. De intranet sites niet, deze werken allemaal op basis van het wildcard record. Dit betekent toch niet dat ik voor alle intranet sites een A en PTR of CNAME record moet gaan zitten toevoegen of wel?

Ik ga denk maar is zoeken naar die registry instellingen. Wederom bedankt Question Mark.

[helaas onderstaande oplossing heeft niet geholpen]
Bij het onderstaande artikel vermoed ik een oplossing gevonden te hebben, deze heb ik dan ook gebruikt en hopelijk heb ik geen last meer van mijn probleem.

support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q245/4/37.ASP&NoWebContent=1
[/helaas onderstaande oplossing heeft niet geholpen]

[ Voor 30% gewijzigd door 0528973 op 26-01-2004 17:00 ]

[Verwijderd]

heb je niet een proxy staan?

als je via nslookup je intranet servers kan goed resolven dan zou het moeten werken. PTR records zijn niet boeiend voor dit geval.
enige uitzondering die ik kan bedenken is als je een proxy hebt draaien die het verkeer weer "terugstuurt" je netwerk op.

btw win2k en hoger gebruiken eerst hostfile, daarna dns en als laatste wins bij het opvragen van een host. kan je de websites wel op ip bereiken?

[ Voor 23% gewijzigd door Verwijderd op 26-01-2004 11:40 ]

[0528973]

Nee ik heb geen proxy staan, wat ik heb staan staat netjes vermeld in mijn openingsbericht.

[Verwijderd]

0528973 schreef op 26 januari 2004 @ 11:38:
Nee ik heb geen proxy staan, wat ik heb staan staat netjes vermeld in mijn openingsbericht.

heb je 1 subnet of staat de intranetserver op een ander segment ?

[0528973]

Er is maar 1 subnet, dat net zoals de hybride instelling van de windows machines zal ik nog even in me openingspost vermelden.

[Verwijderd]

nogmaals, op ip kan je de sites wel bereiken? zo ja, resolving probleem.
btw, waarom draai je wins?

[ Voor 17% gewijzigd door Verwijderd op 26-01-2004 13:16 ]

[0528973]

op ipadres zijn de sites niet te bereiken intern, omdat ze allemaal op hetzelfde ipadres zitten. Via hostnames kan je bepalen welke site je moet openen.

WINS is een onderdeel van Samba, vanwege VPN connecties ed hebben we WINS nodig.

[Verwijderd]

ok zet als test de url's in de hostfile in 1 van de machines. werkt het dan wel?

doe je overigens een ping op fqdn?

[0528973]

Zoals ik al eerder heb gepost in dit topic heb ik een registry hack toegepast, welke op de website van microsoft netjes beschreven staat. Natuurlijk gaat die ping ed werken als ik de websites ga vermelden in mijn host file. Maar dat is nu niet echt een lekkere oplossing is het niet, als ik voor 10 machines het host-bestand moet gaan aanpassen voor elke keer dat ik een nieuwe intranet site toevoeg of verwijder. Voor alsnog lijkt de registry hack mijn probleem hier opgelost te hebben.

En ja, ik doe de ping of zowel de fqdn als de niet fqdn.

Misschien is dit voor niet-linux/samba mensen nog een interessante link om even naar te kijken:
http://www.ocf.berkeley.edu/~linux/mirror/macwin.html

[ Voor 19% gewijzigd door 0528973 op 26-01-2004 16:40 ]

[Verwijderd]

dnscaching heeft weinig met dit te maken... maar als je niet wilt troubleshooten... fine by me...

[0528973]

ik wil wel trouble shooten, maar wat je vroeg heeft tenminste in mijn ogen geen nut. Zoals ik nu in een eerdere post gewijzigd hebt, bleek de registry hack niet te werken en de hostfile vraag van jou wel.

Door de dnscache leeg te laten zijn hoopte ik mijn machine te kunnen dwingen om steeds de nameserver terug te laten geven wat het bijbehorende ipadres van een intranet site zou moeten zijn.

Troubleshooten vind ik geen probleem, maar kom dan met iets meer uitleg waarom ik zoiets zou moeten doen, aangezien dat per default zou moeten werken en zal werken. Wanneer zoiets al niet meer werkt betekent dat dat of me windows machine heel erg bagger geinstalleerd is en er een of andere bug optreed of dat mijn verbinding bagger is.

In dit geval durf ik aan beide mogelijkheden te twijfelen, omdat de connectie zonder meer goed blijft te zijn en er andere machines zijn waarop het wel fatsoenlijk werkt.

Oftewel troubleshooten doe ik graag, ik vind het fijn om zelf in te zien waarom een probleem optreed en hoe ik het kan oplossen... Maar geef dan een iets betere reden waarom ik iets wat zo goed als per default werkt en dus ook gewoon werkt hier moet testen...

[Verwijderd]

0528973 schreef op 26 januari 2004 @ 16:29:
Natuurlijk gaat die ping ed werken als ik de websites ga vermelden in mijn host file.

ik lees: dat ga ik niet proberen want dat werkt toch wel. troubleshooten is 1 voor 1 dingen uitsluiten en dat doe je dus op deze manier...
ik heb tenminste nog niet gezien dat je een http pagina dan kan openen...

[ Voor 11% gewijzigd door Verwijderd op 26-01-2004 17:32 ]

[0528973]

Zodra ik het in me host file neergooi, krijg ik idd een HTTP pagina voor me neus
Mag ik weten waarom je dat zo graag wilt weten en in welke richting qua problemen je zit te denken... Op die manier kan ik namelijk zelf verder zoeken en hier posten wat ik zo af en toe tegen kom als oplossing. Of wat ik dan weer denk dat het zou moeten zijn.

[Verwijderd]

het enige wat ik me dan nog kan voorstellen is dat door de wildcard je http request niet de volledige url wordt maar alleen de domainname. (www.adres.nl wordt in de request meegestuurd als adres.nl). sniffer gebruiken om daar achter te komen...

[0528973]

Helaas dat vermoeden begon ik ook al te krijgen... Ik ga vandaag maar eens een sniffer op me machine installeren, tcpdump zal me hier niet meer mee kunnen helpen denk ik.

[0528973]

ii5_rulez, als zoiets zou gebeuren dan wordt er in mijn geval verzocht om een
pagina 'lan' als mijn intranet pagina's hier hebben de vorm van "naam"."lan"
alles wat opgevraagd wordt op *.lan wordt door gestuurd naar de interne webserver. Zoiets zou ik idd kunnen terugvinden met een sniffer... toch maar eens uitzoeken hoe ethereall werkt dan.

Indien hier mensen zijn met andere ideeën die me zouden kunnen helpen, laat ze dan horen aub.

[Boudi]

Ik denk dat je een WINS probleem hebt. Nslookup gebruikt altijd alleen DNS-servers voor name-resolving. Dit werkt. Pingen (op een client) werkt in een volgorde die je hebt opgegeven via DHCP. Het fijne weet ik er niet meer van, maar vroeger op NT4 zette ik altijd een waarde in de scope properties op '0x8' en dat hield dan volgens mij in dat de clients eerst WINS, dan DNS en dan broadcast deden bij een ping (of een andere verzoek tot name resolving, bijvoorbeeld het openen van een website....)

Wat je even zou moeten proberen: zet je DHCP-server zo in, dat er geen gegevens meer over WINS-servers aan de clients worden meegegeven. Dat moet voor Win2K/XP geen probleem zijn (ik werk al jaren zonder WINS server....)

Als je nu geen problemen meer hebt weet je volgens mij dat het aan WINS ligt, en dat je daar moet zoeken....

Je zegt dat je WINS nodig hebt voor VPN-verbindingen... maar waarom dan precies??? Win2K/XP clients hebben volgens mij altijd genoeg aan een dns-server.....

[Question Mark]

Volgens mij maakt de TS gebruik van hostheader names binnen IIS. Dit heeft altijd de volledige DNS-namen nodig om te weten welke virtuele web-site aangesproken dient te worden. Geen Wins dus. bovendien gebruiken XP/W2K clients die in hybrid mode (0x8) staan altijd eerst DNS voor Wins.

[0528973]

De TS maakt gebruikt van apache onder linux, ipv IIS onder NT oid, het komt er idd op neer dat ik gebruik maak van de volledige dns name om naar een bepaalde website te kunnen resolven.

[Verwijderd]

Wij hebben exact hetzelfde probleem met Win2000/WinXp clients.
In ons netwerk gebruiken we enkel DNS voor nameresolving dus geen WINS.
Steeds weer als het probleem zich voordoet (meerdere keren per dag) kan je via "nslookup <naam>" wel het IP krijgen maar krijg je bij "ping <naam>" een unknown host.
Ook hier is het zo dat "ipconfig /renew" de boel tijdelijk terug oplost.

[0528973]

Hey, toch wel fijn om te horen dat ik hier niet de enige met dit probleem ben. Ik neem aan dat nog niemand een permanent werkende oplossing gevonden heeft?

Zijn er misschien nog hints en tips voor een n00b-netwerk trouble shooter voor dit soort problemen behalve dan dat ik het netwerk verkeer kan gaan sniffen op de momenten dat het goed gaat en wanneer het misgaat.

[Verwijderd]

zo moeilijk is sniffen niet. zeker niet als je alleen dns(wins)/http verkeer hoeft te bekijken. kan je zo lezen...

meten is weten, geldt ook hier

[0528973]

iis5_rulez,
Het is voor mij ook geen probleem om te meten met een sniffer...
Moet ff de handleiding van Ethereal lezen zodat ik de juiste filters ff kan opschrijven, ik had meer zoiets van zijn er nog andere stappen welke genomen kunnen worden om het probleem beter te lokaliseren of om het eventueel te kunnen reproduceren door mezelf. Het netwerk verkeer ga ik binnenkort ff sniffen, maar indien er nog andere stappen of mogelijkheden zijn dan wil ik die graag weten zodat ik die een volgende keer voordat ik hier ga posten zelf kan uitvoeren.

[0528973]

Op het moment ben ik gezellig al mijn dns en wins verkeer aan het loggen over de hele dag en vanavond of morgen gaat ik eens uitzoeken wat er gebeurt als het mis gaat en wat er gebeurt als het goed gaat.

[0528973]

Tijdens het loggen van zowel de werkende als niet werkende situaties ben ik het volgende verschil tegengekomen: het resolven van de intranetsite hostname naar ipadres via DNS.

Tijdens een werkende situatie worden de volgende requests in de hierna genoemde volgorde door de windows machine uitgevoerd:
DNS request(als deze faalt, wordt de volgende stap uitgevoerd)
WINS/Netbios Unicast(als deze faalt, wordt de volgende stap uitgevoerd)
WINS/Netbios Broadcast(als deze faalt, wordt er gemeld unknown host)

Tijdens een niet werkende situatie worden de volgende requests in de hierna genoemde volgorde door de windows machine uitgevoerd:
WINS/Netbios Unicast(als deze faalt, wordt de volgende stap uitgevoerd)
WINS/Netbios Broadcast(als deze faalt, wordt er gemeld unknown host)

Heeft hier iemand enig idee, waarom Windows zomaar ineens geen DNS-request uitvoert en waardoor dit kan komen? Dit gebeurt zowel in de situatie dat de TTL van mijn dnscache 1 seconde of 86400 seconden is.

Onze dhcp server, geeft door dat er 3 nameservers zijn. Hiervan zijn er 2 die niet onze intranet sites kennen(dat zijn externe nameservers). Zou het misschien zo kunnen zijn dat Windows en Mac machines niet standaard de eerste nameserver gebruiken om een hostname te resolven, maar dat ze soms een andere(bijv de tweede) gebruiken?

[ Voor 43% gewijzigd door 0528973 op 03-02-2004 16:40 ]

[Verwijderd]

client cache bedoel je?

volgens mij pakt een client altijd de eerste, maar heeft wel een timeout en gaat dan door naar de tweede... als mislukte queries ook nog gecached worden verklaart het dat er geen dnsquery is...

(hoe/waar log je de wins en dns verkeer?)

[ Voor 55% gewijzigd door Verwijderd op 03-02-2004 16:52 ]

[0528973]

ik log alles op de server waar het aan gevraagd wordt en ja ik bedoel inderdaad de client cache. Wat ik heb nagelezen op microsoft.com is dat negatieve queries idd gecached worden in de client cache.(Deze negatieve qeuries heb ik idd in de cache teruggevonden en zouden verklaard kunnen worden door het feit dat informatie over de intranet sites aan een externe nameserver worden opgevraagd).

Ik heb echter geen idee, waarom er een time-out zou kunnen optreden. Ik heb nu ook een log lopen op onze router om te zien of er idd dns-requests over onze intranet sites naar de externe nameservers gestuurd worden.

Wat er nu is gedaan om het probleem op te lossen is voor mij pc de externe nameservers eruit gehaald zodat ik alleen nog maar de interne nameserver ingesteld heb staan. Hopelijk heb ik geen last meer van deze problemen.

----------------------------------------------------------------------------------------------------------

Na nog meer loggen in zowel de vernieuwde en oude situatie is naar voren gekomen dat windows 2k en xp niet op de standaard wijze gebruik maken van hun nameserver instellingen.

We hadden 3 nameserver, waarvan 2 externe en 1 interne ingesteld via dhcp. De interne werd netjes overal als primaire nameserver ingesteld, windows spreekt soms zonder duidelijke redenen een secundaire of tertaire nameserver aan.

We hebben nu 2 interne nameservers welke alle intranet adressen op de juiste wijze resolven en een cache bijhouden van alle externe adressen.

Voor alsnog lijkt dit de oplossing te zijn.

[ Voor 31% gewijzigd door 0528973 op 03-02-2004 17:40 ]

[Verwijderd]

Ook bij ons hebben we als primaire nameserver eentje die alles kent (dus intern) en nog twee externe die geen interne kent. Als we het probleem terug voorhebben zal ik nog eens nagaan of de externe adressen bereikbaar blijven.
Mogelijks zou het weglaten van de externe nameservers dus een work-around zijn (maar niet echt een oplossing).

[0528973]

@ kc,

Het is een workaround maar ook een oplossing, het probleem zit dieper als dat ik het kan oplossen. Bovendien is een nette en meestal standaard nameserver structuur, dat zodra je een primaire hebt je zelf toch ook netjes een secundaire opzet. Hoewel dit qua theorie niet nodig lijkt te zijn, zijn er dus situaties waarin dit dus wel nodig is. Je kan ook gewoon alleen je eigen nameserver via dhcp laten doorgeven, die secundaire hoef je niet in te vullen.

Indien je een betere oplossing/workaround weet hoor ik hem graag.

kc als het misgaat, moet je op die client machine ff in het dnslog van windows zoeken naar het desbetreffende record(ipconfig /displaydns)
Het probleem zou je dan direct kunnen oplossen door een ipconfig /flushdns te doen.

[Verwijderd]

0528973 schreef op 09 februari 2004 @ 10:39:
kc als het misgaat, moet je op die client machine ff in het dnslog van windows zoeken naar het desbetreffende record(ipconfig /displaydns)
Het probleem zou je dan direct kunnen oplossen door een ipconfig /flushdns te doen.

Heb ik dus gedaan...
Voor deze waarbij het misgaat krijg ik in de log:
Negative cache entry for no records
een ipconfig /flushdns lost niets op een ipconfig /registerdns lost het probleem wel op.
De externe adres-lookup's blijven ook werken wel zie ik dat Windows blijkbaar zelf diverse DNS-lookups gaat uitvoeren. Als ik vanaf een clean cache een ping uitvoer naar www.<iets>.be krijg ik in de cache niet alleen www.<iets>.be maar ook <iets>.be en al zijn alias records dus bv. ook de firma die het DNS-record beheert voor www.<iets>.be. Voor alle Alias-records gaat windows dan ook nog zelf opnieuw een DNS lookup uitvoeren.
Mogelijks ligt hier ergens een probleem met 'interne' machines waarbij er in mijn geval niet altijd extra gegevens beschikbaar zijn.