The NixSPAM black-list is a DNS block-list created by Bert Ungerer of ix. It contains automatically generated entries from open proxies, relays, dialup gateways, etc., and the list is rather popular hereabouts.
Black-listed entries are automatically removed after 12 hours if no further spam from that particular source is detected within that time frame.
You can download a very small subset of the list which is updated
every quarter of an hour. What you should do though, is to configure it as a
DNSBL and access it via the DNS at
ix.dnsbl.manitu.net. At the time of
this writing, the black-list has over half a million records in it, but the
size depends on the amount of spam detected.
I'm working for a customer who is setting up a dedicated system to mirror the list. Whereas copies of a DNSBL you want to host yourself are often transmitted via rsync before being served via the DNS, the NixSpam list is supplied via DNS zone transfers to authorized parties.
The customer has a large BIND DNS infrastructure and wanted the NixSpam black-list to also run on BIND, so we started doing that. (I had my doubts: not about BIND, which is one of the most versatile servers around, but about the load BIND would cause for this particular zone, as the server is one of the public mirrors for the zone.)
We very soon noticed that BIND was consuming quite a bit of the dedicated machine's resources, and the customer asked me to "fix that". :-) I decided we'd replace the name server for the DNSBL with NLnet Labs' NSD, because I knew it would impose a lower load on the hardware. (I knew because I'd slammed NSD (and all the other authoritative name servers I wrote about two years ago) with quite a bit of load two years ago, and NSD came out authoritatively as the fastest authoritative server.)
NSD supports incoming IXFR zone transfers as well
as AXFR, so it was basically a matter of installing and configuring it as a
slave to the
ix.dnsbl.manitu.net zone master, shutting down BIND on this
machine and starting up NSD. Service continued after only a few seconds
downtime, and the average load on the machine dropped from a steady 1.6
through 2.3 to a 0.06 thru 0.46.
We'll be monitoring this closely, but I don't think there'll be a reason to not use NSD for the task. I was able to replace BIND on this system with NSD because I don't need all the bells and whistles that BIND has to offer. NSD is currently handling several NOTIFYs per second and isn't breaking into a sweat.