DNS-lookup lahmt

perl-fan

perl-fan

Grünschnabel
Hallo!

Seit einigen Tagen habe ich einen neuen DSL-Router, eine "Vodafone EasyBox A 600 W-LAN". Das gleiche Gerät hatte ich zuvor auch, es musste aber getauscht werden weil das DynDNS-Update nie funktionierte und ich immer wieder Verbindungsabbrüche hatte.
Jetzt sieht alles soweit gut aus, nur Lahmt der DNS-Lookup für jede Webseite die ich eingebe, und zwar massiv:
Wenn ich nach einem Neustart "google.de" tippe, steht für ca 30(!) Sekunden "Looking up google.de..." in der Statuszeile. Hat er sich ausgeguckt, ist die Seite blitzflink da. Auch Suchen geht sehr schnell. Doch sobald der DNS-Eintrag aus dem Cache gelöscht wird (so nach 1ner Minute in der ich nichts von der Seite anfordere) geht das Spielchen von vorn los.
Google ist natürlich nur ein Beispiel.
Ich habe auch schon die Nameserver-Einträge im Router manuell vergeben (10 verschiedene Einträge von meinem ISP bzw. Arcor, außerdem über 20 andere) und die Router- sowie PC-Firewall deaktiviert: Keine Veränderung.
Was kann ich sonst noch tun?

Vielen Dank schon mal und
Grüße aus dem Norden...
 
DNS-lookup in Mozilla lahmt

Hallo!

Inzwischen hab' ich rausgefunden, dass das Problem auf Windows-Rechnern nicht existiert und bin in dieses Forum gewechselt.
Leider kann ich an meinem Router nicht alle Einstellungen prüfen/manipulieren, da Vodafone mit Setup-Schlüsseln und nicht mit Datenblättern arbeitet: Einige Reiter und Menupunkte sind deaktiviert.

Mein Setup: Vodafone/Arcor "DSL EasyBox A 600 W-LAN" => (9er Switch =>) Rechner.
Code: 
lenny:~# ifconfig eth0
eth0      Link encap:Ethernet  Hardware Adresse 00:12:79:xx:xx:xx 
          inet Adresse:192.168.2.101  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6-Adresse: fe80::212:79ff:fe5d:2fe0/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:40572 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37291 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:33920565 (32.3 MiB)  TX bytes:4388698 (4.1 MiB)
          Interrupt:20

Als Ursache ausgeschlossen habe ich - soweit mir das möglich ist:
  • Firewall des Routers
  • Firewall des Rechners
  • Nameserver (über 30 verschiedene probiert)
  • Paketverluste
  • QoS Paketplaner (Router)

Außerdem ist merkwürdig, dass Links 2.0 keine Probleme hat - alle anderen schon:
  • Links => max. 1s
Code: 
Links (2.1pre37); Linux 2.6.26-1-686
  • Mozilla => ca. 10 - 40s
Code: 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032803 Iceweasel/3.0.6 (Debian-3.0.6-1)
Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.0.7) Gecko/20080528 Epiphany/2.22
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko Galeon/2.0.6 (Debian 2.0.6-2.1)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko Kazehakase/0.5.4 Debian/0.5.4-2.2
  • ELinks => ca. 10s
Code: 
ELinks/0.11.4-3-lite (textmode; Debian; Linux 2.6.26-1-686 i686; 80x24-2)
  • Lynx => ca. 10s
Code: 
Lynx/2.8.7dev.9 libwww-FM/2.14
  • wget => ca. 10s
Code: 
lenny:~$ wget http://www.useragentstring.com/
--2009-04-02 09:29:21--  http://www.useragentstring.com/
Auflösen des Hostnamen »www.useragentstring.com«.... 213.203.223.46
Verbindungsaufbau zu www.useragentstring.com|213.203.223.46|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: nicht spezifiziert [text/html]
In »index.html« speichern.

  [   <=>                         ]   3.841       --.-K/s   in 0,02s

2009-04-02 09:29:31 (168 KB/s) - »index.html« gespeichert [3841]


Woran kann das liegen? Was kann ich tun?

Vielen Dank im Vorraus -
und Grüße aus dem Norden!
 
IIRC hat(te?) Debian ein solches Problem mit Lookups bei einigen Routern. Ein funktionierender aber hässlicher workaround ist, in der /etc/resolv.conf den Nameserver deines Providers oder eines offenen DNS statisch einzutragen.
 
Hi Navy!

Guter Hinweis doch es scheint nicht die Lösung zu sein. Oder mache ich etwas falsch?
Code: 
echo "nameserver 145.253.2.139" | resolvconf -a eth0
Egal welche IP ich angebe, im Anschluß schafft es der Rechner gar nicht mehr, Hostnamen aufzulösen!? Ich habe es mit offiziellen Servern meines ISPs probiert als auch mit ein paar freien und immer das gleiche Resultat.

Grüße
Michael
 
Moin! (so sagt man doch im Norden, hm? :p)

Hast Du mal versucht einen direkten Hostname-Lookup zu machen - ohne die Browser?
Ich vermute stark das es dann keine Probleme gibt, das würde schon mal erklären warum nicht all Deine Browser das gleiche Problem haben:

Code: 
du@dort:~$  dig www.tutorials.de

; <<>> DiG 9.5.1-P1 <<>> www.tutorials.de
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27480
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.tutorials.de.		IN	A

;; ANSWER SECTION:
www.tutorials.de.	340	IN	A	88.198.67.118

;; Query time: 24 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Fri Apr  3 09:44:29 2009
;; MSG SIZE  rcvd: 50

Gruß
Enum
 
Zuletzt bearbeitet:
Hallo Enumerator,

Du hast recht! dig (kannte ich nicht, danke!) braucht nur ein paar Millisekunden um den Hostnamen aufzulösen. Allerdings bekomme ich in meiner Ausgabe auch das hier
Code: 
;; WARNING: recursion requested but not available
Sagt das vielleicht etwas über die Ursache des Problems?
 
Nein, die Warnung hat nicht wirklich was mit Deinem Problem zu tun. Die kommt bei mir auch, das hängt vom Host ab. In dem Beispiel oben hatte ich ursprünglich einen anderen Host, aber ich wollte hier keine Werbung machen und hab's geändert... ;-)
Da Du dig nicht kanntest, gehe ich davon aus das Dir vielleicht auch traceroute, netstat, nslookup und viele der unzähligen anderen Netzwerk und -Diagnose Tools unbekannt sind. Du solltest Dir die Zeit nehmen, deren manpages zu lesen.
So, zurück zu Deinem Problem: Ich vermute Du hast Schwierigkeiten mit IPv6. Soweit mir bekannt ist, kann Links 2 damit auch umgehen, dennoch ist das eine Erklärung dafür warum einige Netzwerkzugriffe über Hostnamen flott gehen und andere nicht. Füge doch einfach mal in /etc/icewasel/pref/iceweasel.js folgende Zeile ein - bzw. ändere false zu true falls die Zeile schon existiert:
Code: 
pref("network.dns.disableIPv6", true);

Wenn jetzt nach einem Neustart des Browsers das Problem behoben ist... kannst Du entweder IPv6 gar nicht erst mit laden, indem Du in /etc/modprobe.d/aliases die folgende Zeile einfügst bzw. anpasst:
Code: 
# vormals "ipv6" anstelle von "off"
alias net-pf-10 off

... oder aber Du lässt es einfach so wie es ist (mit dem Eintrag in iceweasel.js, was aber den anderen Browsern/Tools nicht hilft) oder Du machst es gründlich und suchst exzessiv nach der genauen Ursache bis Sie behoben ist...

Gruß
Enum
 
Hallo "Enum"!

Das hat gehofen! Allerdings nur den Mozilla-Browsern, der Eintrag in /etc/modprobe.d/aliases hat irgendwie keinen Effekt erzielt. Immerhin kann ich jetzt ohne langes Warten "exzessiv nach der genauen Ursache" suchen :-)

Vielen Dank!
 
Moin!

perl-fan hat gesagt.:
Das hat gehofen! Allerdings nur den Mozilla-Browsern, der Eintrag in /etc/modprobe.d/aliases hat irgendwie keinen Effekt erzielt.
Zum Vergrößern anklicken....

Hm, Du kannst jetzt alle ~/*/prefs.js erstmal ändern... Lol.
In /etc/modprobe.d/aliases kannst Du auch noch diesen Eintrag vornehmen:
Code: 
# vormals ip6_queue
alias net-pf-16-proto-13 off

Dannach dürften auch wget und Konsorten wieder fit sein.

Gruß
Enum
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück