Moin,
ich habe auf meinem Desktop einen kleinen DNS-Cacher namens dnsmasq installiert. Wenn ich mich auf einen bestimmten Rechner im Internet per ssh verbinden will dauert das mit laufendem dnsmasq ewig lange (20 Sekunden) bis der Login-Prompt kommt, wenn der aus ist, geht es sehr schnell (<2 Sekunden). Ein Netzwerktrace zeigt, daß diese Zeit vorwiegend mit DNS-Anfragen vergehen (Standard query PTR), interessanterweise *nachdem* die ersten SSH-Paket ausgetauscht wurden. Ein erster Gedanke war, daß mein eigentlicher DNS-Server (Fritz-Box) nicht der authoritative Server ist. Darum habe ich in die dnsmasq-Config eingetragen, daß Anfragen nach Servern in dieser Domain grundsätzlich auf den authoritative DNS-Server gehen. Geholfen hast das nicht.
Hat jemand eine Idee, wo ich suchen kann? Die Netzwerktraces kann ich gerne zur Verfügung, würde Sie aber ungern öffentlich posten.
Danke, Hilmar
Hej Hilmar!
2011-01-26 18:11, Hilmar Preuße skrev:
ich habe auf meinem Desktop einen kleinen DNS-Cacher namens dnsmasq installiert. Wenn ich mich auf einen bestimmten Rechner im Internet per ssh verbinden will dauert das mit laufendem dnsmasq ewig lange (20 Sekunden) bis der Login-Prompt kommt, wenn der aus ist, geht es sehr schnell (<2 Sekunden).
Schuss ins Blaue: IPv4 vs IPv6.
DNSmasq versucht einen IPv6-Lookup, der erst nach einem Timeout fehlschlägt.
Probier mal bei deaktiviertem dnsmasq ssh -4 resp. ssh -6. Kommen dann ähnliche Effekte zu Stande?
Beste Grüße Fabian
On 26.01.11 Fabian Hänsel (fabtagon@gmx.de) wrote:
2011-01-26 18:11, Hilmar Preuße skrev:
Moin,
ich habe auf meinem Desktop einen kleinen DNS-Cacher namens dnsmasq installiert. Wenn ich mich auf einen bestimmten Rechner im Internet per ssh verbinden will dauert das mit laufendem dnsmasq ewig lange (20 Sekunden) bis der Login-Prompt kommt, wenn der aus ist, geht es sehr schnell (<2 Sekunden).
Probier mal bei deaktiviertem dnsmasq ssh -4 resp. ssh -6. Kommen dann ähnliche Effekte zu Stande?
Ich gehe davon aus, daß Du meintest, es bei aktiviertem dnsmasq zu testen (also in den Zustand in dem es lange dauert). Verwendung von -4 hilft nicht.
hille@drachi:~$ ssh -6 -X ehealth@www.e2emplsreporting.de ssh: Could not resolve hostname www.e2emplsreporting.de: Name or service not known
H.
Hallo,
Hilmar Preuße hille42@web.de (Mi 26 Jan 2011 18:11:05 CET):
Moin,
ich habe auf meinem Desktop einen kleinen DNS-Cacher namens dnsmasq installiert. Wenn ich mich auf einen bestimmten Rechner im Internet per ssh verbinden will dauert das mit laufendem dnsmasq ewig lange (20 Sekunden) bis der Login-Prompt kommt, wenn der aus ist, geht es sehr schnell (<2 Sekunden). Ein Netzwerktrace zeigt, daß diese Zeit vorwiegend mit DNS-Anfragen vergehen (Standard query PTR), interessanterweise *nachdem* die ersten SSH-Paket ausgetauscht wurden.
Hier wäre es hilfreich, etwas genauer zu sagen, oder zu zeigen, was in diesen PTR-Queries gefragt wird und wohin die gehen.
Ist das abhängig von dem bestimmten Rechner.
Ein erster Gedanke war, daß mein eigentlicher DNS-Server (Fritz-Box) nicht der authoritative Server ist. Darum habe ich in die dnsmasq-Config eingetragen, daß Anfragen nach Servern in dieser Domain grundsätzlich auf den authoritative DNS-Server gehen. Geholfen hast das nicht.
Nun, wenn es PTR-Queries sind, dann hilft das sicher nicht, dann müsstest Du die Server für die reverse Zone eintragen.
Hat jemand eine Idee, wo ich suchen kann? Die Netzwerktraces kann ich gerne zur Verfügung, würde Sie aber ungern öffentlich posten.
Dann gerne per PM.
On 26.01.11 Heiko Schlittermann (hs@schlittermann.de) wrote:
Hilmar Preuße hille42@web.de (Mi 26 Jan 2011 18:11:05 CET):
Moin,
Ein Netzwerktrace zeigt, daß diese Zeit vorwiegend mit DNS-Anfragen vergehen (Standard query PTR), interessanterweise *nachdem* die ersten SSH-Paket ausgetauscht wurden.
Hier wäre es hilfreich, etwas genauer zu sagen, oder zu zeigen, was in diesen PTR-Queries gefragt wird und wohin die gehen.
Ich habe den Trace doch veröffentlicht: http://home.amasol.de/~preusse/dns_traces.zip . Passwort fürs ZIP-File ist "lug-dd" (ohne die "). Das eine File ziegt den Verbindungsaufbau bei gestopptem dnsmasq (wo), das Andere mit laufendem (w).
Ist das abhängig von dem bestimmten Rechner.
Kann ich leider nicht sagen. Es gibt nur diesen einen Rechner mit dem Setup, ich müßte noch eine VM aufsetzen, um die Frage beantworten zu können.
nicht der authoritative Server ist. Darum habe ich in die dnsmasq-Config eingetragen, daß Anfragen nach Servern in dieser Domain grundsätzlich auf den authoritative DNS-Server gehen. Geholfen hast das nicht.
Nun, wenn es PTR-Queries sind, dann hilft das sicher nicht, dann müsstest Du die Server für die reverse Zone eintragen.
Die PTR Queris kommen in beiden Traces vor. Was tun die Dinger?
Danke, Hilmar
Hallo Hilmar,
Hilmar Preuße hille42@web.de (Do 27 Jan 2011 12:38:30 CET):
On 26.01.11 Heiko Schlittermann (hs@schlittermann.de) wrote:
Hilmar Preuße hille42@web.de (Mi 26 Jan 2011 18:11:05 CET):
Ist das abhängig von dem bestimmten Rechner.
Kann ich leider nicht sagen. Es gibt nur diesen einen Rechner mit dem Setup, ich müßte noch eine VM aufsetzen, um die Frage beantworten zu können.
Ich meinte den Zielhost, sorry, hätte mich genauer ausdrücken sollen.
nicht der authoritative Server ist. Darum habe ich in die dnsmasq-Config eingetragen, daß Anfragen nach Servern in dieser Domain grundsätzlich auf den authoritative DNS-Server gehen. Geholfen hast das nicht.
Nun, wenn es PTR-Queries sind, dann hilft das sicher nicht, dann müsstest Du die Server für die reverse Zone eintragen.
Die PTR Queris kommen in beiden Traces vor. Was tun die Dinger?
Wie es aussieht, versuchen sie den Hostnamen für die Adresse, auf die Du Dich verbunden hast, zu ermitteln.
Da ich keine A-Query sehe, hast Du die IP des Ziels entweder in irgendwelchen Caches gehabt, oder direkt auf der Kommandozeile angegeben. (Nee, im anderen Trace (wo) sind noch die Anfragen nach dem Zielhost zu sehen.)
Ich denke, der SSH-Client möchte den Hostnamen wissen (für die known_hosts?)
Aber etwas merkwürdig kommt mir folgendes vor (aus dem Trace MIT dnsmasq):
15:41:55.265663 IP 192.168.178.21.32649 > 192.168.178.1.53: 44411+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:41:55.265969 IP 192.168.178.21.32649 > 192.168.178.1.53: 44411+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:41:55.311507 IP 192.168.178.1.53 > 192.168.178.21.32649: 44411 ServFail 0/0/0 (44)
... warum stellt er die selbe Frage (Query-ID) noch mal: als hätte er die Antwort nicht mitbekommen 15:42:00.268572 IP 192.168.178.21.32649 > 192.168.178.1.53: 44411+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:42:00.268840 IP 192.168.178.21.32649 > 192.168.178.1.53: 44411+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:42:00.317539 IP 192.168.178.1.53 > 192.168.178.21.32649: 44411 ServFail 0/0/0 (44)
und hier aus dem File ohne DNSMASQ:
15:43:23.164666 IP 192.168.178.21.53167 > 192.168.178.1.53: 46353+ A? www.fiducia.e2emplsreporting.de. (49) 15:43:23.169355 IP 192.168.178.1.53 > 192.168.178.21.53167: 46353 1/2/0 A 217.111.8.202 (112)
... hier wird auch die selbe Frage zweimal gestellt, aber das kann daran liegen, dass die wenige Millisekunden vorher eingetroffenen Antwort noch nicht bis zum lokalen resolver durch ist
15:43:23.169609 IP 192.168.178.21.55445 > 192.168.178.1.53: 5039+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:43:23.215382 IP 192.168.178.1.53 > 192.168.178.21.55445: 5039 ServFail 0/0/0 (44) 15:43:23.215475 IP 192.168.178.21.60379 > 192.168.178.1.53: 5039+ PTR? 202.8.111.217.in-addr.arpa. (44) 15:43:23.261352 IP 192.168.178.1.53 > 192.168.178.21.60379: 5039 ServFail 0/0/0 (44)
15:43:23.262128 IP 192.168.178.21.60001 > 192.168.178.1.53: 52899+ A? www.fiducia.e2emplsreporting.de. (49)
Was ich jetzt noch nicht verstehe - wieso bekommst Du Antworten, obwohl Dein DNSMASQ aus ist? Was steht in beiden Fällen in der Resolv-Conf?
Im Fall MIT DNSMASQ: 127.0.0.1 und OHNE 192.168.178.1
Wenn das so ist, dann gehe ich mal davon aus, daß DNSMASQ im Falle von ServFail etwas mehr Geduld aufbringt und meint, er müsste nach 5 Sekunden die Frage noch mal wiederholen - entweder weil der die Antwort nicht genschnallt hat, oder weil er meint, bei ServFail noch mal die selbe Frage mit der selben Query-ID stellen zu dürfen. Der Stub-Resolver, der direkt, ohne DNSMASQ den Forwarder fragt, fragt im Falle von ServFail zwar auch noch ein paar mal nach, aber trödelt nicht so lange rum.
Firewallprobleme will ich mal ausschließen, denn positive Antworten bekommst Du ja auch rein.
Ist aber alles ziemlich geraten. Vielleicht probiere ich das heute Abend mal von zu Hause, müsste bei mir ja ähnlich sein.
On 27.01.11 Heiko Schlittermann (hs@schlittermann.de) wrote:
Hilmar Preuße hille42@web.de (Do 27 Jan 2011 12:38:30 CET):
On 26.01.11 Heiko Schlittermann (hs@schlittermann.de) wrote:
Moin,
Ist das abhängig von dem bestimmten Rechner.
Kann ich leider nicht sagen. Es gibt nur diesen einen Rechner mit dem Setup, ich müßte noch eine VM aufsetzen, um die Frage beantworten zu können.
Ich meinte den Zielhost, sorry, hätte mich genauer ausdrücken sollen.
Ahh, OK. Nein, es sind 3 Systeme betroffen: www.tamplsreporting.de, www.e2emplsreporting.de, www.fiducia.e2emplsreporting.de Wenn man die Dinger mit HTTP anspricht geht der Seitenaufbau recht flott.
Da ich keine A-Query sehe, hast Du die IP des Ziels entweder in irgendwelchen Caches gehabt, oder direkt auf der Kommandozeile angegeben. (Nee, im anderen Trace (wo) sind noch die Anfragen nach dem Zielhost zu sehen.)
Ich verwende für den Connect keine IP-Adresse, insofern maximal Cache. Der spielt in dem Fall aber keine Rolle. Es kann sein, daß ich bei einem Trace nicht früh genug angefangen habe zu sniffern, so daß diese Requests nicht zu sehen waren. Ich bin mir nicht ganz sicher, ob ich beim Trace auch auf lo0 gesniffert habe. Wenn ich das nicht gemacht habe, sind DNS-Anfragen zum dnsmasq natürlich nicht zu sehen. Das werde ich noch nachholen.
Jetzt: http://home.amasol.de/~preusse/fid_w_dnsmasq1.zip Da drin sind auch A-Queries, wenn dnsmasq läuft. Sorry für die Konfusion!
Was ich jetzt noch nicht verstehe - wieso bekommst Du Antworten, obwohl Dein DNSMASQ aus ist? Was steht in beiden Fällen in der Resolv-Conf?
root@drachi:~# less -X /etc/resolv.conf nameserver 127.0.0.1 search amasol.de root@drachi:~# /etc/init.d/dnsmasq stop Awakening mail retriever agent: fetchmail. Stopping DNS forwarder and DHCP server: dnsmasq. root@drachi:~# less -X /etc/resolv.conf nameserver 192.168.178.1 search amasol.de
Die 192.168.178.1 ist die Fritz-Box. Das "search amasol.de" erklärt den Versuch www.fiducia.e2emplsreporting.de.amasol.de aufzulösen.
Wenn das so ist, dann gehe ich mal davon aus, daß DNSMASQ im Falle von ServFail etwas mehr Geduld aufbringt und meint, er müsste nach 5 Sekunden die Frage noch mal wiederholen - entweder weil der die Antwort nicht genschnallt hat, oder weil er meint, bei ServFail noch mal die selbe Frage mit der selben Query-ID stellen zu dürfen. Der Stub-Resolver, der direkt, ohne DNSMASQ den Forwarder fragt, fragt im Falle von ServFail zwar auch noch ein paar mal nach, aber trödelt nicht so lange rum.
Also eher ein Bug in dsnmasq? Die Changelogs von 2.55 in Debian geben in der Richtung noch nichts her. Ich habe die jetzt für mich compiliert und installiert -> keine Besserung.
Danke, Hilmar
lug-dd@mailman.schlittermann.de
-
Fabian Hänsel -
Heiko Schlittermann -
Hilmar Preuße