Montag, 11. Juni 2007, 16:45
Nächste Umstellung der iX-Blacklist
Aufgrund nur durchschnittlich guter Erfahrungen mit dem derzeitigen Setup PowerDNS + MySQL für die DNS-Blacklist ix.dnsbl.manitu.net gehen wir derzeit auf eine Lösung aus BIND mittels dynamischer Updates.
Die beiden rbldns' kommen nicht in Frage. Sie unterstützen zwar ebenfalls Updates zur Laufzeit in Form von Neuladen der Zone, jedoch ist die iX-Blacklist wirklich "live", die Zone ändert sich mehrere Male pro Minute. Dafür wurden diese beiden einfach nicht gemacht.
BIND, wenn gerne auch als Monster bezeichnet, performt hier mittels nsupdate sehr gut. Wer die "neue" Liste testen möchte, erreicht sie via
Die beiden rbldns' kommen nicht in Frage. Sie unterstützen zwar ebenfalls Updates zur Laufzeit in Form von Neuladen der Zone, jedoch ist die iX-Blacklist wirklich "live", die Zone ändert sich mehrere Male pro Minute. Dafür wurden diese beiden einfach nicht gemacht.
BIND, wenn gerne auch als Monster bezeichnet, performt hier mittels nsupdate sehr gut. Wer die "neue" Liste testen möchte, erreicht sie via
ix-new.dnsbl.manitu.net(z.B. für SpamAssassin oder seinen MTA).
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Micha
Bert Ungerer
noledge
rein für den einsatz mit der dnsbl nicht so gut (performance?) oder generell nicht so empfehlenswert?
Manuel Schmitt (manitu)
nighthawk
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.
Robert Felber
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.
Manuel Schmitt (manitu)
Robert Felber