Keine DNS-Antworten mehr nach 5-15min

Hi Habo.

Folgendes Szenario:
Mein Netgear FWG114P bekommt über DHCP seine Nameserver(195.34.133.13/.20) von meinem Provider(UPC Austria) zugeteilt. Auf meiner Linux-Kiste mit fixer IP im Lan hab ich 10.0.0.1 als Nameserver in /etc/resolv.conf eingetragen.

Nach 5-15 min surfen bekomme ich keine DNS-Antworten mehr rein, weder über Browser noch über dig. Eigentlich ist UPC ja so nett und liefert bei einer nicht existierenden Domain eine Suchseite zurück, aber selbst diesen Blödsinn spielts dann natürlich auch nicht mehr.

Zuerst dachte ich UPC macht mal wieder Blödsinn mit ihren DNS-Servern, und hab am Router Primary und Secondary DNS vertauscht(Obwohl beim Ausfall des Primarys die Anfrage doch an den Secondary gestellt werden sollte, oder?). Schwupps, es funktioniert wieder, für 5-15min! Dann muss ich die beiden wieder vertauschen. X(

Der letzte Absatz lies mich an ein Problem mit dem eingebauten DNS-Server meines Netgear-Routers glauben, UPC wird ja wohl nicht beide Server im 10min Takt ein- und ausschalten.
Trage ich jedoch beide Server direkt in die resolv.conf ein, funktionierts nach 5-15min auch nicht mehr. Dann hilft nur längeres warten. Was den Router als Ursache doch eigentlich ausschließen sollte, da DNS auf Layer 4 des TCP/IP-Modells arbeitet und der Router keine bestehenden Verbindungen zu Webservern unterbricht und auch neue zulässt, sofern ich Webserver direkt über die IP anspreche, mich auf ein und der selben Seite durchklicke.

In einer Windows-Virtualmachine die über DHCP ihre Daten von meinem Router bekommt, besteht das Problem auch.
Eventuell habe ich auch Stoff für den Linux-Flame Thread, aber die Verbindung der Virtualmachine wird Linux wohl nicht versch******, hoffe ich.

Hilfe, bitte! :wall:
 
Den Caching DNS des Routers als DNS eintragen macht unter Linux häufig Probleme. Abhilfe schafft dann im Normalfall das Eintragen der DNS des Providers direkt in der resolv.conf. Natürlich müssen dann auch die DHCP-Einstellungen des Clients so angepasst werden, dass er seine DNS-Einstellungen nicht mehr vom Router bezieht.
 
Also das Benutzen der OpenDNS-Server in der /etc/resolv.conf schafft Abhilfe. Sind zwar nicht die schnellsten, jedoch besser als alle 10min was zu ändern...

Ich werds jetzt nochmal mit den Servern vom Provider in der /etc/resolv.conf probieren, vlt hat mir die zwei Stunden die ich mit dem testen dieser direkt in der /etc/resolv.conf verbracht habe, einfach der übliche Verbindungsabriss dazwischengefunkt X(

Wiens Fibernetwork soll endlich zu mir ausgebaut werden :/
 
@Bitmuncher: Öhm, seit wann ist denn das so? Hat Linux etwa generell ein Problem mit lokalen Nameservern ;-) ..?!?

@simsim: Ich würde mal auf dem Router die DNS Server wechseln.
 
@Bitmuncher: Öhm, seit wann ist denn das so? Hat Linux etwa generell ein Problem mit lokalen Nameservern ;-) ..?!?

Meiner Erfahrung nach ja. Bei 1 von 3 Netzwerken funktioniert es meiner Erfahrung nach nicht, wenn man den Router als DNS bei nem Linux-Desktop einträgt, solange dieser keinen Bind9 laufen hat. Ich rätsel bis heute, warum das so ist.
 
Sorry, ich kann das so einfach in keiner Form bestätigen. Wenn das deinem Alltag entspricht wäre eine echte Analyse bestimmt interessant.. Hm, OT ...
 
Kannst ja mal im Unixboard und hier nach Einträgen zu DNS-Problemen mit Linux suchen, wo ich geantwortet habe. In den meisten Fällen hat mein Tipp geholfen. Betrifft aber halt auch primär Hardware-Router. Privat hatte ich dieses Problem aber auch schon mit Routern von Cisco und Level One. Eine echte Analyse hat mich bisher noch zu keinem Ergebnis geführt, obwohl ich darin bereits viele Stunden Zeit investiert habe.
 
Ich kann es halt einfach nicht bestätigen. Ich denke es wäre ein weltweites Thema wenn dem so wäre. Den Begriff Hardware-Router finde ich schwer zu interpretieren. Der Begriff ist zwar irgendwie absurd, aber die meisten würden dann doch bestimmt Level-One und Cisco ebenfalls in diese Kategorie stecken. Wie gesagt eine auf die Situation bezogene Problembeschreibung und Analyse wären sicherlich interessant. Und wenn es dann immer die selbe Thematik betrifft, kommt man damit bestimmt ins Fernsehen ;-) ..
 
Beispiele:
http://www.unixboard.de/vb3/showthread.php?t=36765
http://www.unixboard.de/vb3/showthread.php?t=25291
http://www.unixboard.de/vb3/showthread.php?t=23964

Ich müsste jetzt genauer suchen um den Rest noch zu finden, aber man kann diesbezügliche Lösungen dutzende Mal im Web finden. Allein ich habe mit diesem Lösungsweg schon min. 2 Dutzend Usern in den letzten Jahren geholfen und auch in meinem beruflichen Alltag damals zu meiner Freiberuflerzeit bin ich immer wieder über dieses Problem gestolpert. Wir hatten dieses Problem sogar schon versucht auf der Kernel-Mailingliste zu analysieren, sind aber auch dort nicht zu einer Lösung oder wenigstens einer Fehlerursache gekommen. Es ist nunmal einfach Tatsache. Ich persönlich gehe ja davon aus, dass es ein Designfehler im Network Layer des Kernels ist, aber das Versuch mal dem "Ich bin Gott Mr. Cox" klarzumachen. :/
 
Sei mir nicht böse, aber zwei Postings aus 2006 und eins aus 2008.. Ich nutze und betreue homogene Landschaften seit vielen Jahren. Und ich habe von diesem generellen Problem noch nichts gehört. Von DNS Problemen in den unterschiedlichsten Formen natürlich schon. Aber sicherlich von keinen derartigen Generalproblemen. Hast du das wirklich bei der Kernel-Mailingliste eingereicht? Das würde mich jetzt wirklich interessieren! Hast du evtl. Links zu den entsprechenden Mailarchiven?
 
Zuletzt bearbeitet:
Da müsste ich jetzt erstmal suchen. Ist schon einige Jahre her. Damals hatte ich meinen ersten DSL-Anschluss und einen Level One Router und hab diese halsstarrigen Leute, die sich Kernel-Entwickler nennen, noch unterstützt. Muss also schon min. 5-6 Jahre her sein. Und die Links sind nur Beispiele. Google ist dein Freund. Ich supporte Linux jetzt seit >10 Jahren sowohl beruflich als auch privat und bin seit sich DSL verbreitet immer wieder über dieses Problem gestolpert. Kannst ja z.B. mal bei SexyMF nachfragen, ob er in seiner resolv.conf vorher den Router als DNS drin stehen hatte, wenn du ein aktuelles Beispiel haben willst. Da er im Thread http://www.hackerboard.de/network-l...uration-bei-opensuse-11-1-nicht-moeglich.html von "geändert" sprach, gehe ich mal davon aus. Hatte das aber nicht weiter hinterfragt. Im übrigen leg ich aber auch nicht wirklich Wert drauf, ob du's glaubst. ;) Ich weiss was ich an Erfahrungen gemacht habe und gebe diese lediglich weiter. Bei 10.000-15.000 Beiträgen von mir in diversen Foren kann ich unmöglich Buch führen wie oft einzelne Probleme aufgetreten sind. Aber nicht umsonst schrieb ich schon 2008, dass sich dieses Problem ja langsam rumgesprochen haben sollte. Also viel Spass beim Suchen. Mir ist dafür meine Zeit zu schade. In meinem Blog kann man lesen, dass ich Linux zwar noch supporte, aber nicht mehr unterstütze. Also werde ich sicherlich auch keine Zeit mehr investieren um irgendwelchen alten Kamellen aufzuwärmen, die seit zig Jahren immer wieder auftreten und bis heute nicht gefixt sind. Dass sie immer wieder auftreten sollte durch die gebrachten Beispiele ausreichend belegt sein. :rolleyes: Wenn du mehr willst oder die Hintergrundinfos dazu, such halt selbst.
 
das problem ist meines wissens ein alter bis sehr alter hut, und in den fällen die mir begegnet sind ist schlicht der router das problem gewesen:

manche der kleineren dsl router für zuhause haben keinen vernünftigen, sprich standard konformen DNS server/cache ... in der regel recht leicht zu testen ... frag mal was anderes als einen A record an ... z.B. PTR oder MX ...

das problem was die meisten linux distributionen mit diesem sachverhalt haben, ist dass gerne mal die eine oder andere "exotischere" (sprich nicht windows-übliche) anfrage verschickt wird... da UDP als träger protokoll verbindungslos ist wartet deine kiste dann bis zum timeout des DNS clients ... mitunter auch mal ne halbe stunde oder länger auf die antwort die nie kommen wird ... meines wissens stößt er dann irgendwann an eine ressourcengrenze und allen neuen requests gehen in die warteschlange, bis durch timeout ressourcen frei werden

mit einer lösung des eigentlichen problem des clients hab ich mich nie befasst, da es bis dato schneller und einfacher war mal eben nen bind9 dazwischen zu setzen ...

windows hat übrigens prinzipiell das gleiche problem ... stellt man z.B. mit nslookup bei betroffenen routern zu viele anfragen, die nicht verarbeitet werden können, stößt auch windows an eine ressourcengrenze und die namensauflösung verweigert den dienst ... nur ist hier das timeout an heutige verhältnisse angepasst wurde, und der zustand keine 2 minuten anhält ...
 
Ich hab noch nie erlebt, dass Windows das gleiche Problem hat und auch MacOSX hat mit den Routern kein Problem, genauso wie FreeBSD. Da es eben mit Win und *BSD immer keine Probleme gab, kamen wir ja damals auf die Idee, dass das Problem mit dem Kernel und nicht mit dem Router zu tun hat.
 
daher schrieb ich "prinzipiell" ... du kannst das problem unter windows provozieren, aber im normalfall tritt es nicht ein, da die router nicht DNS implementieren, sondern darauf getrimmt sind das zu beantworten was windows normalerweise anfragt ...

prinzipiell reichts ja, nur wird die abweichung vom eigentlichen standard zum problem, wenn der dns client absurde timeout-werte hat, oder allgemein nicht gut mit seinen ressourcen umgeht.

der dns client im bind zeigt dass es auch anders geht ...

an der stelle treffen unglücklicher weise 2 ungünstige implementierungen aufeinander ... zum einen der router, der DNS nur halb kann, zum anderen ein DNS client, der zwar DNS kann, aber nicht gerade robust auf weiderkehrende fehler reagiert ... wer hats nun verbockt? meiner meinung nach die leute die den router verbrochen haben, der wenn er was nicht kann, einfach nichts sagt, anstelle das laut DNS spezifikation vorgesehene "not-implemented" zu antworten... das würde beim client zumindest die ressourcen wieder frei geben ...

//edit:
natürlich wäre es ein leichtes für ein robusteres verhalten des clients zu sorgen, aber in mancher hinsicht scheinen gewisse maintainer und deutsche behörden die gleiche mentalität zu haben
 
Zuletzt bearbeitet:
Mittlerweile habe ich hier noch ein Winxp aufgesetzt und das Ganze durchgetestet. Mit DNS-Servern über DHCP klappts perfekt, mit dem Router als DNS die selbe Sache wie unter Linux. Wenn ich nach dem Wechsel von 10.0.0.1 als DNS wieder auf DHCP wechsle, bekomme ich ein paar Minuten keine DNS-Antworten mehr. Ich werde einfach nicht schlau daraus und bleibe bei DNS über DHCP :wall:
 
@bitmuncher: Du verallgemeinerst einfach zu stark. Es ist mir kein generelles Problem der DNS-Implementierung unter Linux bekannt! Dabei bleibe ich insofern du nicht den Gegenbeweis antrittst. Dazu werde ich sicherlich nicht Google durchstöbern o. mir deine Posts raus suchen. Der von dir genannte hatte ohne Zweifel nichts mit dem hier geschilderten Problem gemeinsam. Versteh mich bitte nicht falsch! Ich denke einfach das es sich um spezifische Probelme handelt die man nicht verallgemeinern darf. Ansonsten wäre deine Theorie nach der Antwort von simsim ja verloren..

@GrafZahl: Yeep, mit minderwertigen Routern haben letzendliche alle Betriebssyteme Probleme. Aber wenn es so leicht wäre, das wirklich durch ausbleibende DNS-Antworten zu bewerkstelligen, hätten wir wohl ein riesen Problem. Wenn es sich um ein Problem des Timeouts handelt, einstallbar per resolv.conf. Ein Problem der Buffersize, einstellbar per sysctl. Eine der leichtesten DOS-Attacken aller Zeiten? Unwahrscheinlich, aber wer weiss ;-) ? Und was ich mich noch frage ist was ein Linux anderes per DNS anfragt als WIndows?

@simsim: Wenn du schreibst "per DHCP" meinst du wahrscheinlich das du dir die alternativen DNS-Server verpassen lässt?!? Es wäre jetzt wirklich interessant zu wissen was passiert, wenn du das ganze nochmal auf deinen Router zurückstellst und dann nur eines der Syteme hochfährst. Wenn das DNS-Problem dann auftritt, fährst du das nächste System hoch. Hat es sofort die selben Probleme?
 
Und was ich mich noch frage ist was ein Linux anderes per DNS anfragt als WIndows?

ein beispiel: man nehme eine windows shell und eine linux shell ... in beiden führe man ein nslookup auf google.com. aus ... du bekommst einen satz adressen mit round robin ... die linux maschine wird dir aber aller wahrscheinlichkeit nach zusätzlich für jede der erhaltenen adressen den PTR eintrag holen ... die windows maschine nicht

die systeme tun offensichtlich das was man angefordert hat ... nur "das drumherum" unterscheidet sich an diversen stellen geringfügig (so geringfügig, dass man durchaus ab und an 2 mal hingucken muss) ...

solche unterschiede reichen aber oft aus, speziell wenn manche geräte die standards nicht einhalten und mit der heißen nadel gestrickt sind, um mit einer art von system tadellos zu laufen, bei jeder anderen probleme ohne ende zu verursachen
 
Zurück
Oben