Michael Scheidell wrote:
...and I bet there are still commercial anti-spam products using
dsbl.org because they haven't figured it out either :-)
Wasn't there a standard at one time, return something different (test) if
you queries 2.0.0.127.{dnsblacklist}?
There's a draft or two that attempt to standardize and/or describe best
practices.
If it returned (at least) '127.0.0.2'
and a list of other valid bitflags. that meant that the dnsbl was up and
running? Anything else and it wasn't?
most DNSLs list 172.0.0.2 and do not list 127.0.0.1, so a cron that
checks these two IPs every day can help detect problems and send an
alert, or even disable a DNSL if the problem persists.
for example:
$ host 1.0.0.127.relays.ordb.org
1.0.0.127.relays.ordb.org has address 127.0.0.2
shows that ordb should be removed.
but in the dsbl case, 127.0.0.2 is still listed:
$ host 2.0.0.127.list.dsbl.org
2.0.0.127.list.dsbl.org has address 127.0.0.2
even if the zone is empty.
host 2.0.0.127.zen.spamhaus.org.
2.0.0.127.zen.spamhaus.org has address 127.0.0.2
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
I am glad SA has sa-update, because in the tradition of the other dead
blacklists, they will either stop producing the zone, take server offline,
or return 127.0.0.2 for everything like a couple of zones do(did).
yes, the ordb case has caused a lot of problems, in particular for sites
using commercial appliances (symantec, ...).
In this case, testing would be easy enough (if you decided to do that),
since it timesout.
not in the dsbl case. it will return NXDOMAIN (except for 127.0.0.2).
