I woke up this morning to a barrage of complaints from users that our mail servers' outbound emails are bouncing due to a blacklisting. Sure enough, mxtoolbox.com<http://mxtoolbox.com> reports that rbl.iprange.net<http://rbl.iprange.net> has blacklisted us for more than a day. However, looking up our address on the rbl.iprange.net<http://rbl.iprange.net> lookup webpage shows we're NOT listed. But a check of the RBL's DNS shows that we are. Then I found this on the rbl.iprange.net<http://rbl.iprange.net> owner's website ():
What the heck? I've tried contacting realtimeblacklisk.com<http://realtimeblacklisk.com>, but they're in the Netherlands and apparently fast asleep (in more ways than one, it seems).
We had a Charter IP address we don’t actually send email from (it is a backup line that would only send mail if our primary line was down) Blacklisted by these guys at 10:50am EST on 1/1/18, then removed at 3:34pm EST on 1/1/18.
MXToolBox alerted us to it, I ran a manual check on their portal, which is supposed to be http://iprange.net/rbl/lookup/ but redirects to https://realtimeblacklist.com/lookup/ and it came back not listed. Since it was a line I knew we were not mailing from anyways I figured I would just deal with it in the morning, but it had cleared itself up by then.
Given this behavior on their part, it would seem best to not only
immediately remove their old DNSBL from mail system configurations,
but to never add their new one.
Apparently they're widely used by firewall-based anti spam, as we seem to be getting blocked a lot by Juniper, Sonicwall, and Palo Alto firewalls. The outfit is listed in https://en.m.wikipedia.org/wiki/Comparison_of_DNS_blacklists, but seem to have very poor communication options (e.g., WhoIs is obscured).
Why don't they just quit answering DNS queries at rbl.iprange.net? Sheesh!
As the message said, they use this to force mx admins to remove their entry to stop hammering. I remember other lists did the same. Contact the remote mx admin in order to get this fixed.
I did finally reach someone at realtimeblacklist.com. They've just today shut down the bogus DNS RBL and said they realize now it was a terrible idea. They read and now understand the RBL RFC and promised not to do it again. I appreciate them taking the time to respond, and hopefully they'll also improve their communication channels (such as putting meaningful contact info in their WhoIs. It's ironic that an anti-spam operator, of all people, would hide this info!)
But what other people have rightfully pointed out is that his behavior
is stupid and against the RFC that covers DNSBLs. And it's not simply
MX admins here. You have firewalls that are also affected.
If you're going to run a DNSBL to advertise your mail software,
perhaps do so in a way that doesn't flip the bird at everyone using
it.
On Tue, Jan 02, 2018 at 04:46:02PM +0000, Mel Beckman quoted:
"rbl.iprange.net will mark every ip address as listed to force removal of this server."
Apparently they didn't read section 3.4 of RFC 6471:
I agree that listing the world is a bad idea but I feel their pain,
having a few DNSBL-like things here that are hammered on at great
length by broken clients. If you want the traffic to go away, what do
you do?
I run a little DNS server at contacts.abuse.net that provides abuse
contact information in TXT records. For reasons I can only imagine, a
few hosts hammer on them like crazy (one seems to have the goal of
looking up every 2ld in the .at domain) which is a pain. So I've
started doing nameserver poisoining. If one of those annoying hosts
asks for, say, foo.bar.contacts.abuse.net which is how you ask for the
contacts for domain foo.bar, it returns
with 12 fake NS records with randomish hostnames. Then when they do A
or AAAA lookups for those host names, I send back a couple of dozen fake
A or AAAA records. In my experience that makes them go away pretty
fast, with only the occasional revisit when they want something in an
obscure TLD that I haven't poisoned yet.
This is all written in perl, which turned out to be pretty easy, and
not using Net::DNS or anything like that, either. I suppose if I
wanted to do this on behalf of a normal nameserver I could use some
packet filters to divert traffic from annoying hosts to the poison
server.
If you're going to run a DNSBL to advertise your mail software,
perhaps do so in a way that doesn't flip the bird at everyone using it.
On the other hand if you're going to use DNSBLs, you really should do
the tests in RFC 5782 every once in a while so you stop using BLs that
don't exist any more. It's not hard.
Alas, these RBLs are often hard-coded into firewalls. Non-sophisticated users just think they have a check box saying "block spam". Fixing those IS hard.
Alas, these RBLs are often hard-coded into firewalls. Non-sophisticated users just think they have a check box saying "block spam". Fixing those IS hard.
I believe there are cases where people have made it hard, but there are limits on how much I believe in protecting people from the consequences of their ineptness.
Perhaps we should spin up a little DNS cache just for DNSBL queries.