-----BEGIN PGP SIGNED MESSAGE-----
Frank Ellermann wrote:
Chris Lewis wrote:
Many DNSBLs are already multi-valued (zen.spamhaus.org presently has
6 independent "flags"), and they can be constructed to be more
sophisticated with as many as 2^24 values on a single return, and/or
being used in scoring.
Thanks for info, I still had "sbl-xbl" instead of "zen" in a script.
I'd really love it if they'd take the same approach as SURBL (or the
former OPM) with sets represented by bits. At the moment they have
apparently eight sets (2, 4,5,6,7,8, 10,11) encoded as integers.
They've mentioned 8, but they're only _using_ 6. 2 are "reserved" ;-)
The items for XBL are somewhat in a state of flux, so they're basically
telling people that if you trust XBL, you can trust any of the other two
values if they become "real".
Using bits 1..8 (127.0.0.2 up to 127.0.1.0) they could get a similar
effect, and even indicate if IPs belong to more than one set at the
same time. That's what multi.surbl.org does (with 6 sets), and Jeff
asked implementors to support at least bits 1..15 for 15 sets.
I _used_ to prefer bitmapped DNSBLs, but I've been persuaded (and
learned thru personal experience) otherwise.
One main reason why they're not using bitmaps is the difficulty in
construction. If you use bitmaps, you have to explicitly merge each
entry when you build your zone - completely reconstructing the zone
file. With big DNSBLs that can be quite time-consuming just to do a
hack job. There isn't any freeware code presently available to do that.
Spfilter, for example, will die the "out of memory" death if you try to
combine, say, CBL and one or two other large DNSBLs, and doesn't have a
way to intelligently combine A records anyway (spfilter only merges
(part of) the TXT record, but not across ranges).
We used to use spfilter. Remembering those days makes me cringe. Was
taking over an hour to merge when I finally killed it.
In contrast, rbldnsd makes it trivial to merge. Each zone retains its
separate identity, as a separate file if you wish. Munging entries is
completely optional. rbldnsd simply returns _all_ matching records in a
single DNSBL query.
By "hack job", I mean that most merging mechanisms (including spfilter)
trying to derive a single (eg: bitmapped) entry does not handle nesting
at all. Eg: trying to coalesce a /24 PBL entry, a /22 SBL entry, and a
/32 XBL entry into a single bitmap is computationally difficult and
This matters both to the DNSBL publisher, and the user of DNSBLs who
wishes to use local servers. Like us.
We're currently using about 10 DNSBLs (5 of them locally constructed).
All of them are combined into local rbldnsd under a single query. Aside
from some TXT mangling needed to make FP handling more consistent, and
remapping A values so that we have unique values across all subzones, we
don't actually have to _look_ at the zone contents when we merge - just
tell rbldnsd "publish these dnsbl files".
Remember it was simple for OPM to do this, because they only listed
/32s, and it was really only one (relatively small) database.
You _have_ to handle multiple A records if you want to deal with varying
range entries so that you get all hits (scoring for example).
In contrast, SORBS, NJABL and Spamhaus (using the combined query naming)
all use the multiple A return approach. NJABL (mostly) publishes them
as a single file, but the entries are not merged.
There have been a few DNSBLs that have had somewhat different return
code schemes. Like one which would return an integer "badness" score.
And another where you could encode specific questions (beyond just the
IP) in the query and get a numeric code back. But they were only
I was going to mention that...
...does it work again ? I've recently removed it because it didn't
pass the "127.0.0.2 listed" test anymore. For similar reasons I've
removed wadb.isipp.com in 2005.
I stopped using it some time ago because it wasn't yielding much. I
should check again. I just turned off SORBSproxy and SORBSsocks (no
longer using SORBS at all), so, I can afford to add one ;-)
I'll direct you to this comment in the bogons zone file:
# This file does not include the following additional iana reserved blocks:
# 10.0.0.0 - 10.255.255.255 - reserved for intranet local networks
# 127.0.0.0 - 127.255.255.255 - reserved for local loop on each computer
# 172.16.0.0 - 172.31.255.255 - reserved for intranet local networks
# 192.168.0.0 - 192.168.255.255 - reserved for intranet local networks
# 220.127.116.11 - 18.104.22.168 - used for multicast routing
In other words, using 127.0.0.2 as a test entry for the bogon list is
more than a bit, shall we say, ambiguous.
If you use the zone file, you can tell whether it's "working" by the
size and datestamp on it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Asrg mailing list