Al Iverson wrote:
Hello all,
I'm new to the list. A lot of familiar names here. If you don't know
me, I've created a few different DNSBLs, mostly back they were
lovingly crafted out of shell scripts using stone knives and
bearskins. Lately I've started cataloging dead DNSBLs and writing up
DNSBL reviews on www.dnsbl.com, a site of mine.
Good to see that you are still around. :) I think I remember at least a
couple of
those stone knife and bearskin lists.
One thing that strikes me as missing from the BCP is some guidance on
usage and implementation in spam filtering and blocking applications.
In particular, technical guidance regarding whether or not a DNSBL
actually exists and can be queried. As I am learning from diving back
in to the thick of DNSBL-related things lately, I see
- Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
years after the RBL moved away from that FQDN.
- Other lists randomly vanishing with no warning and continuing to get
DNSBL traffic for years
- Blars, for example, vanished in December and now lists the world.
- LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
hits years later, resorting to listing the world.
- The occasional ignorant sod who queries something like
random.dnsbl.maps.com which causes unwanted traffic (and potential
unwanted mail blocking) from various sites. (You'll note that maps.com
has a wildcard, for example.)
One of the best pieces of advice I can give for this is to put a DNSBL
on a domain specifically registered for the purpose -- while it's
possible to run one within a subdomain, I would recommend strongly
against it, getting rid of the query traffic if you later shut down is
truly next to impossible, and if you have a dedicated domain, it's
easier to kill the nameservers for it that it would for a domain that
has to remain active even after the DNSBL dies. In other words, a DNSBL
on a domain pretty much poisons it for years to come with substantial
volumes of traffic.
Needless to say, this also places a special responsibility on DNSBL
operators for making sure that their domain registrations stay active
and secure - if allowed to expire prematurely, the impact to downstream
users can be significant, and if allowed to be hijacked malicious
entries could be placed which may result in a denial of service to
legitimate users.
Maybe this is outside of the scope, and if so, I apologize. But if
appropriate, it seems wise to have some guidance included about how to
avoid these situations, preferably recommended that checks be
implemented in software to confirm that a list an application is
checking actually exists and really is a DNSBL.
A standard "listed" test entry and standard "not listed" test entry are
a good way to test that. Standard practice right now usually uses
2.0.0.127.dnsbl.example.com or some variant as the "always listed"
address - adding a requirement for a "never listed" address would be a
good way to implement an additional check to make sure the DNSBL is
still active, and hopefully that it's not listing the world. I'm not
sure that we have a standard convention for a "never listed" test
address (one that should always return a whitelist record or NXDOMAIN
depending on the type of list.)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg