[gelöst] dnsmasq cached DNS-Namen falsch?

derheimi

Mitglied
Mitglied seit
4 Jul 2006
Beiträge
347
Punkte für Reaktionen
0
Punkte
0
Hatte es ein einem anderen Thread schon kurz erwähnt, dass dnsmasq Anfragen aus dem Cache beantwortet, obwohl die schon nichtmehr gültig sind. Ok, zunächst ein paar Fakten für den Überblick. Standort 1: Debian Server, dort wird periodisch und bei Einwahl ein DynDNS-Name aktualisiert. Das funktioniert auch prima, von mehreren (unabhängigen) Systemen aus getestet.
Standort 2: Meine F!B (siehe Sig) mit dnsmasq, dahinter 2 WinXP-Boxen.
Dnsmasq-Config:
Code:
no-poll
log-queries
domain-needed
localise-queries
no-negcache
dhcp-range=192.168.8.30,192.168.8.40,12h
read-ethers
Auf der F!B hab ich den syslog angeworfen, damit dnsmasq ordentlich loggen kann.
Mit einem "kill -SIGUSR1 `pidof dnsmasq`" kann man ja den aktuellen Cache-Inhalt loggen lassen: Voilà:
Code:
Dec 19 10:06:30 fritz daemon.info dnsmasq[2455]: time 1166519190, cache size 150, 0/30 cache insertions re-used unexpired cache entries.
Dec 19 10:06:30 fritz daemon.debug dnsmasq[2455]: Host                                     Address                        Flags     Expires
Dec 19 10:06:30 fritz daemon.debug dnsmasq[2455]: irgendwas.homedns.org                     84.x.y.z                  4F        Tue Dec 19 10:06:30 2006
Auf einer Windows-Box mache ich jetzt ein "ipconfig /flushdns" nur um sicherzugehen, dass die Box selbst nix mehr im Cache hat und dann ein "nslookup irgendwas.homedns.org.". Geloggt wird von dnsmasq nun:
Code:
Dec 19 10:08:29 fritz daemon.debug dnsmasq[2455]: query[A] irgendwas.homedns.org from 192.168.8.1
Dec 19 10:08:29 fritz daemon.debug dnsmasq[2455]: cached irgendwas.homedns.org is 84.x.y.z
Wohlgemerkt:
- die Uhr der FB geht richtig
- in der Zwischenzeit kamen keine weiteren Anfragen bezgl. irgendwas.homedns.org (die hätte es ja sonst auch geloggt)

Mein Fazit: das Cachen beim dnsmasq ist fehlerhaft.
Oder steh ich grad irgendwo auf dem Schlauch?

Beobachtet ev. jmd dasselbe Verhalten? Wäre nett, wenn das mal jemand bei sich testen könnte...

Das Problem ist jetzt, dass sich die IP-Adresse am Standort 1 nach der Zwangstrennung ja ändert und meine Windows-Boxen bekommen immernoch die alte Adresse aus der Konserve, das ist natürlich doof...

Achso: Wenn ich auf der F!B selbst ein "nslookup ..." mache, stimmt alles. Aber das liegt ja daran, dass in der /etc/resolv.conf die nameserver 192.168.180.1 ... angegeben sind, sprich der lokale dnsmasq wird da ja gar nicht gefragt.

Gruß, Michael
 
Ich poste im Laufe des Tages ein neues Binary. Dann könntest du nochmal probieren. Es gibt da ein kleines Problem mit "soft-float"-Berechnungen. Eventuell schlägt auch hier, wie bei dem "--no-poll" Problem der Zeitvergleich fehl. Ich bin an der Lösung des Problems...

MfG Oliver
 
vielleicht ist es auch gar kein software problem?

denn jede nameserver information (fachlich: zone) hat stets eine bestimmte gültigkeit, die vom jeweilig zuständigen nameserver bestimmt wird.

in dem fall sind also die für homedns.org authorativen nameserver verantwortlich, die gültigkeitsdauer festzulegen.

eventuell sind hier zu lange gültigkeiten angegeben, so dass unter umständen veraltete informationen zu lange von den konsumenten (andere nameserver, dnsmasq, clients) vorgehalten werden?

Code:
dig soa homedns.org
liefert die zuständigen dns server.

Code:
dig any irgendwas.homedns.org @zuständiger.server1.com
liefert die aktuellen zoneninformation inkl. gültigkeitsdauer direkt von der quelle

schau mal direkt nach einem update der dynamischen adresse, wie schnell denn wirklich die aktualisierte zone auf dem zentralen dns server vorliegt und was hier für eine gültigkeit angegeben wird?

ein anderes problem könnten die dns server deines providers sein: dns abfragen laufen in der regel baumartig von den blättern zum stamm, immer in der annahme, dass die nächst übergeordnete instanz die antwort vielleicht schon kennt (gecached hat).
wenn die dns server des providers sich ggf. nicht an "die reglen" halten und die dns informationen nicht rechtzeitig aktualisieren, können ebenfalls veraltete informationen weitergegeben werden.
 
Hi,

@knox:
Stimme Dir erstmal in jedem Punkt zu.
Die TTL wird den "dyndns"-Domain ja bewußt niedrig gehalten, bei DynDNS, was auch meine homedns.org handelt, liefert ein dig z.B.
Code:
;; ANSWER SECTION:
irgendwas.homedns.org.   60      IN      A       84.x.y.z

Also TTL=60 Sekunden.

knox schrieb:
wenn die dns server des providers sich ggf. nicht an "die reglen" halten und die dns informationen nicht rechtzeitig aktualisieren, können ebenfalls veraltete informationen weitergegeben werden.


Ich hatte ja geschrieben, das ein "nslookup" auf der FB selbst das korrekte Ergebnis liefert, und da wird ja der Upstream-DNS meines Providers (GMX) gefragt und der fragt direkt bei der Quelle nach. Insofern ist die richtige Antwort ja schon in den übergeordneten Instanzen verfügbar, mehr oder weniger gecached.

Und in der geposteten Logdatei siehst Du, wann der Cache-Eintrag vom dnsmasq expiren sollte und dass die geloggte Anfrage [deutlich] nach dem Expire-Zeitpunkt liegt. Von daher erscheint mir das "soft-float"-Problem näherliegend, obwohl ich mir darunter grad nix vorstellen kann...

Gruß, Michael
 
dnsmasq überprüft per difftime ob die Gültigkeitsdauer überschritten ist.
Problem:
Code:
/var/mod/root $ ./difftime
difftime nan,1166319393,1166319403 <- Labor-Toolchain
/var/mod/root $ ./difftime
difftime 10.000000,1166319539,1166319549 <- alte Toolchain
/var/mod/root $
Code:
#include <stdio.h>
#include <time.h>
 
int main( void )
{ 
    time_t start, end;
    time (&start);
    sleep(10);
    time (&end);
    double dauer;
    dauer = difftime(end,start);
    printf("difftime %f,%d,%d\n", dauer, (int)start, (int)end);
}
Lösung: Das Binary muss mit "-msoft-float" kompiliert werden.

MfG Oliver
 

Anhänge

  • dnsmasq_soft-float.tar.bz2
    51.5 KB · Aufrufe: 12
Das angehängte dnsmasq funktioniert (zumindest im Schnelltest, werde es mal noch ein paar Stunden im Auge behalten, bevor ich den Thread als 'gelöst' markiere) prima: der Cache-Eintrag expired und fliegt raus, bei der anschließenden Query wird die Anfage wieder geforwarded.

Danke für die schnelle Hilfe & Lösung!

EDIT: Bedeutet das eigentlich, dass man dann alles mit -msoft-float compilieren sollte?
 
(im prinzip gehört das hier nicht mehr zum ursprünglichen thema, sondern eher in den 2.6er labor thread)

derheimi schrieb:
Bedeutet das eigentlich, dass man dann alles mit -msoft-float compilieren sollte?
ich habe mal ein paar schlaue leute gefragt und mir das erklären lassen.
demnach ist auf systemen ohne fpu (wie der fritzbox) die berechnung von float auf software basis notwendig.
hierzu gibt es zwei möglichkeiten, eine durch den kernel und eine direkt in der software selbst.
offensichtlich funktioniert die variante im kernel nicht mehr oder zumindest nicht mehr so wie vorher, so dass nun die software-eigene berechnung aktiviert werden muss.
dies ist wohl ein erheblicher performance verlust, aber es gibt keine alternative.
 
Moment, welches von beiden ist langsamer?

olistudent hat mich auf folgendes hingewiesen:
linux/arch/mips/math-emu/cp1emu.c schrieb:
* Note if you know that you won't have an fpu, then you'll get much
* better performance by compiling with -msoft-float!

Mfg
danisahne
 
danisahne schrieb:
welches von beiden ist langsamer?
der vergleich bezog sich auf fpu vs. soft-float.

danisahne schrieb:
olistudent hat mich auf folgendes hingewiesen: linux/arch/mips/math-emu/cp1emu.c
klingt doch vielversprechend.

tut mir leid, ich kenne mich damit selber nicht wirklich aus und habe nur mühsam erlerntes halbwissen weitergegeben :)
 
Ja nun, meines Wissens hat die Fritzbox doch gar keine FPU.

EDIT: Nun die große Frage: Wie wirkt sich das auf die AVM Daemonen aus? Die sind ja wahrscheinlich nicht mit -msoft-float kompiliert.
 
Der Patch betrifft doch aber nur die libgcc und die ist in den AVM-Daemons statisch, oder?

MfG Oliver
 
olistudent schrieb:
Der Patch betrifft doch aber nur die libgcc und die ist in den AVM-Daemons statisch, oder?
Ah, stimmt. Na das is ja praktisch, dann gehen wir doch voll und ganz auf -msoft-float.

EDIT: Hmm, also irgendwie bin ich mir immer noch nicht so sicher, ob man das wirklich hard- und soft-float mischen kann (siehe hier). Gibt das nicht Inkompatibilitäten mit den AVM Binaries?

EDIT2: soft-float verändert die ABI, d.h. das betrifft nicht nur die libgcc.
 
Zuletzt bearbeitet:
Sorry, dass ich das nochmal pushe, aber sonst bekommt ja niemand meine Ergänzungen mit.

Folgendes: hard-float und soft-float kann man wegen ABI Veränderungen nicht miteinander mischen, d.h. wir müssen natürlich dabei bleiben, was AVM benutzt hat. Jedoch hat AVM beim Wechsel auf uClibc-0.9.28 auf soft-float umgestellt.

Mfg
danisahne
 
Kann man das irgendwie rausbekommen, wie ein Programm compiliert ist - abgesehen von den Makefiles? Oder woher hast Du die Info, dass AVM umgestellt hast?
Also dh. für "alte" Firmwares ohne soft-float (das heißt dann wohl mit dem --without-fp, was hier vorher mal irgendwo stand?), für "neuere" mit -msoft-float... oder?
 
Ich zitiere mal spblinux (PN):
spblinux schrieb:
Hi Oliver,

was ich alles wissen soll...

Natürlich ist ein kernel fp emulator schneller als ein (uC)libc userspace emulator. Nur einen kernel emulator muss man haben.

google hat ausgespuckt:
Patch introduces a option, with which you can enable
or disable the FP emulator in the kernel.
It was written to ensure that no user space binaries uses
FP instruction. This was necessary because glibc
still contained some FP instructions even though it
was configured with --without-fp and gcc with --with-float=soft.
See <http://sources.redhat.com/ml/crossgcc/2005-09/msg00054.html>
for details and <http://sources.redhat.com/ml/crossgcc/2005-09/msg00125.html>
for patch.
Quelle (also ein patch der nur so tut, als ob es einen fp emulator gäbe; einfach um den illegal instruction Fehler zu vermeiden).

und in den ohio-sources von avm sehe ich auf die schnelle auch nichts von fpu emulator.

Also bleibt nur der userspace emulator (libm, also uClibc) oder man verzichtet ganz auf floating point. - Wie das obige Zitat zeigt, funktioniert --without-fp wohl nicht immer vollständig; in ungünstigen Fällen scheinen fpu-Reste übrig zu bleiben, die in Spezialfällen Fehler verursachen.

Zusammengefasst gilt nach meiner Erinnerung:
- entweder alles ohne -msoft-float, was perfekt funktioniert, solange man kein Programm kompiliert, das floating point verwendet (sodass die fpu angesprochen wird).

- oder uClibc, gcc (dh. libgcc) werden mit -msoft-float kompiliert und dann müssen alle Programme die floating point verwenden auch mit -msoft-float kompiliert werden (sonst wird falsch gerechnet, durchaus ohne dass das Programm dabei abstürzt, z.B. ignoriert asterisk dann im dialplan festgelegte Wartezeiten).

- äusseres Kennzeichnen für -msoftfloat: libm ist doppelt so gross; die avm *.29 firmware für die die7170 verwendet wohl -msoft-float (grosse libm und zudem libgcc enthalten).

Hoffe das hilft weiter.

Gruss, Christian
MfG Oliver
 
spblinux schrieb:
Zusammengefasst gilt nach meiner Erinnerung:
- entweder alles ohne -msoft-float, was perfekt funktioniert, solange man kein Programm kompiliert, das floating point verwendet (sodass die fpu angesprochen wird).
Es kann durchaus die FPU angesprochen werden, auch wenn keine vorhanden ist, falls - wie im Fall der 2.4er Firmwares - ein Kernel-FPU-Emulator vorhanden ist (das hat natürlich die schlechteste Performanz).
spblinux schrieb:
- oder uClibc, gcc (dh. libgcc) werden mit -msoft-float kompiliert und dann müssen alle Programme die floating point verwenden auch mit -msoft-float kompiliert werden (sonst wird falsch gerechnet, durchaus ohne dass das Programm dabei abstürzt, z.B. ignoriert asterisk dann im dialplan festgelegte Wartezeiten).
Genauso ist es. Daher können wir leider nicht selber entscheiden, ob wir den Kernel-FPU-Emulator oder Software Floating Point verwenden wollen, weil wir die AVM Binaries nicht neu kompilieren können. Aber Hauptsache es funktioniert auf irgendeine Weise.

Die Option --without-fp bezieht sich in dem Zitat von spblinux auf die glibc. Ist das gleichbedeutend mit / entsprechend UCLIBC_SOFT_FLOAT aus der uClibc .config?

Wie lautet die Option für den gcc? --without-float oder --with-float=soft? Letzteres anscheinend für neuere gcc Versionen, aber wenn man in die buildroot Quellen schaut sind da einige Ausnahmen. Muss da mal das passende rausextrahieren.

derheimi schrieb:
(das heißt dann wohl mit dem --without-fp, was hier vorher mal irgendwo stand?)
Hab --without-fp fälschlicherweise als gcc Option interpretiert.

Mfg
danisahne
 
Mit "--with-float=soft" ist kein "-msoft-float" mehr nötig. Es wird immer gesetzt. Auch der Kernel 2.6.13 hat einen FPU-Emulator.
Wir dürfen in der uClibc natürlich nicht den Standard ändern, sonst laufen die AVM-Binaries nicht mehr. Richtig!

Was mir noch nicht ganz klar ist, ist das Zusammenspiel von uClibc und libgcc. Greift die uClibc dann auf die libgcc zu, wenn sie Floating Point Operations durchführen will?

MfG Oliver
 
olistudent schrieb:
Greift die uClibc dann auf die libgcc zu, wenn sie Floating Point Operations durchführen will?
gcc internals

Die Beziehung ist anders herum. Das Programm ruft Funktionen aus der libgcc auf, welche dann auf Funktionen der libc zurückgreift. Wie jede Lib muss auch die libgcc mit den selben soft-float Optionen wie der Rest compiliert werden, wenn ich das richtig verstanden hab.

Mfg
danisahne
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.