Montag, 11. Juni 2007
Nächste Umstellung der iX-Blacklist
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Mal eine blöde Frage, sind beide Blacklists auf dem gleichen Stand? Im Moment habe ich noch beide eingetragen, ix-new wird aber zuerst abgefragt. Bei der Gelegenheit durfte ich dann gleich auch noch feststellen, dass opm.blitzed.org eigentlich sein Mai deaktiviert ist und daher das maillog etwas angeschwollen war 
Nein, sind sie nicht. ix-new hat weniger Einträge und ist, weil sie noch nicht in das automatische Austragungsverfahren eingebunden ist, wirklich nur zum Testen gedacht.
wo liegt das problem beim powerdns+mysql wenn ich fragen darf? wir wollen demnächst einen powerdns als verwaltungs-dns einsetzen, mit dem sich die 2 BINDs, die im internet stehen, abgleichen.
rein für den einsatz mit der dnsbl nicht so gut (performance?) oder generell nicht so empfehlenswert?
rein für den einsatz mit der dnsbl nicht so gut (performance?) oder generell nicht so empfehlenswert?
Für DNSBL in der Tat suboptimal. Die MySQL-Datenbank performt trotz einiger Anpassungen nicht so gut wie gedacht. Sie DNSBL liefert primär negative Ergebnisse (sprich: Nicht enthalten), und die MySQL-DB cacht besser positive Ergebnisse.
Ich habe mir, da ich diese elendigen Timeouts wirklich leid war, eine eigene IX RBL gebaut, die durch herunterladen der zwei Dateien gefüttert wird und mit rbldnsd betrieben wird. Das Setup läuft absolut problemlos und timeoutfrei.
In den letzten Tagen habe ich dann mal einige Statistiken zur IX Blacklist erstellt und muß sagen, daß diese echte Livekoppelung absolut nicht notwendig ist. Viele IPs werden sogar über Tage hinweg verwendet und des dauert größtenteils 2 bis 3 Stunden bis eine gelistete IP versucht bei mir SPAM abzusetzen.
Dann habe ich mir mal die Mühe gemacht nachzuschauen, ob ich durch ein Live-Datenupdate viele Mails zusätzlich geblockt hätte: Das Ergebnis hat meine Bemühungen bestätigt. Es wäre vielleicht eine Mail gewesen.
Demgegenüber läuft das Mailsystem nun insgesamt flotter, weil nicht mehr ständig auf Timeouts der RBL gewartet wird.
Daher hätte ich den folgenden Vorschlag: Bietet doch zwei RBLs an. Eine wird minütlich aktualisiert (ich kenne ja die Datenstruktur in MySQL nicht, aber bei mir dauert das Erzeugen der rbldnsd Zonendateien keine 2 Sekunden - und mein Rechner ist wahrlich nicht der flotteste, minütlich sollte also wohl drin sein).
Und dann halt die Liste mit den Liveupdates, die eben mit gewissen Performanceproblemen kämpft. Manch ein Mailsystem mag das ja durchaus verkraften können.
In den letzten Tagen habe ich dann mal einige Statistiken zur IX Blacklist erstellt und muß sagen, daß diese echte Livekoppelung absolut nicht notwendig ist. Viele IPs werden sogar über Tage hinweg verwendet und des dauert größtenteils 2 bis 3 Stunden bis eine gelistete IP versucht bei mir SPAM abzusetzen.
Dann habe ich mir mal die Mühe gemacht nachzuschauen, ob ich durch ein Live-Datenupdate viele Mails zusätzlich geblockt hätte: Das Ergebnis hat meine Bemühungen bestätigt. Es wäre vielleicht eine Mail gewesen.
Demgegenüber läuft das Mailsystem nun insgesamt flotter, weil nicht mehr ständig auf Timeouts der RBL gewartet wird.
Daher hätte ich den folgenden Vorschlag: Bietet doch zwei RBLs an. Eine wird minütlich aktualisiert (ich kenne ja die Datenstruktur in MySQL nicht, aber bei mir dauert das Erzeugen der rbldnsd Zonendateien keine 2 Sekunden - und mein Rechner ist wahrlich nicht der flotteste, minütlich sollte also wohl drin sein).
Und dann halt die Liste mit den Liveupdates, die eben mit gewissen Performanceproblemen kämpft. Manch ein Mailsystem mag das ja durchaus verkraften können.
Danke schoen, dass Ihr den Versuch startet! Ich weiss, dass das fuer ein Unternehmen, das ja eigentlich auch Geld verdienen moechte, ein relativer Aufwand ist.
Ich habe rein interessehalber mal ein paar Anfragen mit dig abgesetzt, und es scheint sich doch in den response-Zeiten niederzuschlagen:
% dig @217.11.48.18 -t TXT 12.20.12.36.ix-new.dnsbl.manitu.net
;; Query time: 17 msec
% dig @217.11.48.13 -t TXT 12.20.12.35.ix.dnsbl.manitu.net
;; Query time: 41 msec
Die Antwortzeiten liegen ca um 5 bis 40ms auseinander, wobei ix-new jeweils schneller ist. Ich habe immer unterschiedliche Abfragen gesendet, um caching zu vermeiden. Selbst wenn der Service Life waere, duerften sich die Antwortzeiten des BIND nur marginal aendern, vorausgesetzt, der BIND laeuft auf einem adaequaten Rechner (Ich denke, SMP (kein HT) ist Pflicht.)
Auf einem DUAL P3 1,2Ghz schaffe ich mit einem in-arbeit-befindlichen DNS-SpamTrap DNS-Server ca 15000 queries/s (=6Mbit rx+tx bei 33byte packets) (www.ek-muc.de/~robtone/dstsd/ bzw www.ek-muc.de/~robtone/sender-idea.txt)
Die 15000 queries/s sind vermutlich auch Kernel gebunden, das heisst, der Kernel gibt vor (Interrupts, Context-Switche, etc), wie schnell Kind-Prozesse/Threads eines DNS Servers von ein und dem selben Socket lesen koennen, da der Kernel den Socket bereitstellt/verwaltet, und der Socket "laeuft" nunmal auf einer CPU (so zumindest mein Verstaendnis und meine Beobachtungen unter FreeBSD). Der Schluss lag nahe, da ich mit Single- sowie Multithreaded/forked auf 15000 queries/s kam, jedoch nie darueber hinaus.
Ich habe rein interessehalber mal ein paar Anfragen mit dig abgesetzt, und es scheint sich doch in den response-Zeiten niederzuschlagen:
% dig @217.11.48.18 -t TXT 12.20.12.36.ix-new.dnsbl.manitu.net
;; Query time: 17 msec
% dig @217.11.48.13 -t TXT 12.20.12.35.ix.dnsbl.manitu.net
;; Query time: 41 msec
Die Antwortzeiten liegen ca um 5 bis 40ms auseinander, wobei ix-new jeweils schneller ist. Ich habe immer unterschiedliche Abfragen gesendet, um caching zu vermeiden. Selbst wenn der Service Life waere, duerften sich die Antwortzeiten des BIND nur marginal aendern, vorausgesetzt, der BIND laeuft auf einem adaequaten Rechner (Ich denke, SMP (kein HT) ist Pflicht.)
Auf einem DUAL P3 1,2Ghz schaffe ich mit einem in-arbeit-befindlichen DNS-SpamTrap DNS-Server ca 15000 queries/s (=6Mbit rx+tx bei 33byte packets) (www.ek-muc.de/~robtone/dstsd/ bzw www.ek-muc.de/~robtone/sender-idea.txt)
Die 15000 queries/s sind vermutlich auch Kernel gebunden, das heisst, der Kernel gibt vor (Interrupts, Context-Switche, etc), wie schnell Kind-Prozesse/Threads eines DNS Servers von ein und dem selben Socket lesen koennen, da der Kernel den Socket bereitstellt/verwaltet, und der Socket "laeuft" nunmal auf einer CPU (so zumindest mein Verstaendnis und meine Beobachtungen unter FreeBSD). Der Schluss lag nahe, da ich mit Single- sowie Multithreaded/forked auf 15000 queries/s kam, jedoch nie darueber hinaus.
Sorry fuer das aussergewoehnlich lange delay, ich hab die Nachfrage irgendwie nich mitbekommen, link ist nun fixed.
IPv4 vs. IPv6
Du bist hier via
Suche
Ökostrom
Kalender
Kommentare
zu 64 Kerne
Do, 24.05.2012 00:23
Nen bißchen Seti und wir überh
olen die Amis und stehen auf P
latz 1 
zu 64 Kerne
Mi, 23.05.2012 20:45
Selbst bei dieser Kiste sollte
man ein klein wenig SWAP anbi
eten....
zu 64 Kerne
Mi, 23.05.2012 20:39
Müssen wir in Tschernobyl den
Reaktor wieder hoch fahren, we
nn das Teil auf volllast läuft
zu 64 Kerne
Mi, 23.05.2012 20:03
Swap? Auf so einer Kiste?
Sel
bst wenn der auf einer PCIe-RA
Mdisk liegt, versaut es Dir di
e Auslastung der Cores, [...]
zu 64 Kerne
Mi, 23.05.2012 16:22
genau, das meinte ich, danke!
kannte ich noch gar nicht, seh
r schönes Spielzeug, dieses ht
op
