Skip to content
< Vorheriger Eintrag | Nächster Eintrag >

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
ix-new.dnsbl.manitu.net
(z.B. für SpamAssassin oder seinen MTA).

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Micha

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 ;-)

Bert Ungerer

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.

noledge

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?

Manuel Schmitt (manitu)

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.

nighthawk

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.

Robert Felber

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.

Manuel Schmitt (manitu)

Der 2. Link ist tot. Hast Du da noch einen anderen :-) ?

Robert Felber

Sorry fuer das aussergewoehnlich lange delay, ich hab die Nachfrage irgendwie nich mitbekommen, link ist nun fixed.

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen