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