Home / Blogs

An Unwelcome Afterlife for a Long-Dead Blacklist

J.D. Falk

There's still a few weeks before Halloween, but have we ever got a scary story for you—and every word of it is true. (Imagine we're sitting around a campfire, chowing down on s'mores, flashlights under our faces.)

Seven years ago, on this very internet, there was a man named Matthew who was angry about spam. Now sure, there are lots of people angry about spam, and some of them are named Matthew, but this particular Matthew decided that he was going to do something about it.

Matthew noticed that a lot of spam came from foreign countries, and that he didn't get any real mail from people who lived there. So he created blacklists for each country that sent him spam. Then he noticed that a lot of spam came from particular large ISPs, and he created blacklists for each ISP that sent him spam. Soon Matthew had a lot of lists, and some of them were very big.

Five years passed, and suddenly Matthew and his lists disappeared! Nobody knows where they went—well, somebody probably knows, but they aren't telling, and it doesn't matter for this story. What does matter is that everyone forgot about blackholes.us, yet a lot of email systems were still configured to query those lists.

The IP addresses of the blackholes.us nameservers were assigned to somebody else, but those IP addresses continued to receive queries from all of those old email systems. None of those queries ever returned with an answer, yet they would not die! It was a zombie blacklist!

Nobody likes to have a zombie blacklist on their network, but zombie blacklists are nearly impossible to kill. The people who now control those IP addresses made the drastic decision, just a few days ago, to set up new nameservers where blackholes.us nameservers used to be. These new nameservers give the zombie blacklist new life, more virulent and destructive than ever before: they respond to every query as if the IP address were actually on the blacklist!

In other words: if an email server asks about 216.183.97.117, the zombie blacklist will now gleefully say yes! Reject that message!

If an email server asks about 69.63.178.161, the zombie blacklist will now gleefully say yes! Reject that message!

No matter what IP address the email server asks about, the zombie blacklist says yes! Reject that message, and damn the consequences!

"When there's no more room in hell," said a tired survivor hiding in a shopping mall, "the dead will walk the earth." When there's no more room for queries, dead blacklists will list every IP.

The anonymous yet angry people who chose to invoke the dark powers and resurrect this zombie blacklist think that responding with a yes! for every IP address will force email administrators to stop using blackholes.us in their mail servers—and they're probably right. But it'll also cause a lot of legitimate email to be rejected in the meantime, and that sure is unfriendly. The Anti-Spam Research Group (which may also be a zombie now) wrote a document which specifically calls out that method as a bad practice.

There's no happy ending to this story, kids. To quote another scene in that same mall: "When the dead walk, Senores, we must stop the killing—or lose the war."

But this doesn't mean you have to spend your whole life locked inside a mall, hiding from zombies and blacklists. If you send email that appears to be rejected because of blackholes.us, contact the administrator of the site you were sending to, and ask them to read the current blackholes.us web site—bad grammar and all. Tell them there are better blacklists they could be using, operated in accordance with best practices learned from long experience.

Of course, they probably won't get your email, but at least you will have tried.

Time for bed, now. Go on back to your tents, and don't trip over those old headstones. Whose idea was it to camp in an abandoned graveyard, anyway?

(This article was originally published by Return Path Inc. Additional reporting & style consultation provided by Neil Schwartzman.)

Written by J.D. Falk, Director of Product Strategy at Return Path. Visit the blog maintained by J.D. Falk here.

Related topics: DNS, Email, Spam

Get a weekly summary of postings to CircleID:

 Master Feed (more feeds)      Twitter      Mobile
Bookmark / Email This Post

Comments

"Five years passed, and suddenly Matthew and Carl Byington  –  Oct 13, 2009 10:38 AM PST

"Five years passed, and suddenly Matthew and his lists disappeared!"

It seems that blackholes.us is *still* owned by Matthew

Domain Name:  BLACKHOLES.US
Registrant Name:  Matthew Evans
Registrant Email:  matthew@blackholes.us

"The IP addresses of the blackholes.us nameservers were assigned to somebody else, but those IP addresses continued to receive queries from all of those old email systems."

That is slightly incorrect. The ip addresses that are receiving those queries are specified in the NS records for blackholes.us. Presumably, the same folks that wrote the content on <http://www.blackholes.us> have control of those dns servers.

And, as Vernon Schryver points out in news.admin.net-abuse.email, there are trivial ways to avoid the dns queries. Whoever runs the dns servers for blackholes.us could simply add

chinanet.blackholes.us.  8640000 IN NS dummy.blackholes.us.
countries.blackholes.us. 8640000 IN NS dummy.blackholes.us.
dummy.blackholes.us.  8640000 IN A 192.0.2.1
dummy.blackholes.us.  8640000 IN A 192.0.2.2

And repeat for all the subdomains which were used for the actual blacklists. I don't happen to have a complete list of them, but a tcpdump of the dns query stream would quickly find them all.

So the folks that control the dns servers for blackholes.us could easily avoid that query stream, but they don't seem to realize that.

The easiest way to fix this... Ian Woollard  –  Oct 13, 2009 10:52 AM PST

...is probably to blackhole the blackhole.us domain's IPs.

That way all of the DNS requests will get eaten. If you're feeling aggrieved you would blackhole it only in the inbound direction to your network, and only the received packets will be eaten, and they'll still have to handle it. ;-)

Of course the real fix to this is IP-v6.

unclear Carl Byington  –  Oct 13, 2009 8:26 PM PST

It is unclear just which party you think should ignore packets.

Machine A sends mail to machine B which is configured to use some $sublist.blackholes.us dnsbl. A dns server near B sends a query towards the ip addresses specified by the blackholes.us servers.

The gtld.biz servers are publishing glue for the dns servers for blackholes.us that points to 216.243.118.35.

It seems that the new owners of 216.243.118.35 have nothing to do with the domain blackholes.us other than receiving queries at that ip address due to the glue in the gtld.biz servers. So they setup an actual dns server on 216.243.118.35 to answer those queries with a wildcard A record, thereby shooting themselvs in the foot. They should have that dns server instead return long TTL NS records for the various subdomains of blackholes.us pointing into 192.0.2.0/24 space.

"That way all of the DNS requests will get eaten. If you're feeling aggrieved you would blackhole it only in the inbound direction to your network, and only the received packets will be eaten, and they'll still have to handle it. ;-) "

So, who do you think should do this filtering of dns packets? Some machine near A, near B, or near 216.243.118.35? These packets never get anywhere near A. B is the machine that is actually sending these dns requests, so rather than filtering them or their responses, it is easier to simply configure the mail server at B to not use blackholes.us. 216.243.118.35 can filter them by ignoring them, but it still chews up their inbound bandwidth. So I fail to understand your suggestion.

"Of course the real fix to this is IP-v6."

I fail to see how that would affect this situation in any way, given that the mail servers involved are all sending queries for A records, and given that the glue published by gtld.biz is an A record as well.

If you're annoyed at them deliberately screwing Ian Woollard  –  Oct 13, 2009 8:51 PM PST

If you're annoyed at them deliberately screwing up your your mail, you should block the *replies* from network.us, not the packets leaving your network. That way they still have to process it. Your software will probably try to make connections periodically. Presumably you would get around to fixing this properly… eventually. Blackholing somebody that is deliberately screwing you about is appropriate.

IPv6 is a fix for this, because the IP addresses don't need to be repeated because there's so many, so *nobody* should get them reallocated to them.

are you advocating being impolite? Carl Byington  –  Oct 14, 2009 12:00 PM PST

"If you're annoyed at them deliberately screwing up your your mail, you should block the *replies* from network.us, not the packets leaving your network. That way they still have to process it."

It seems that in my example above, that "you're annoyed" is B.

So you advocate deliberately sending packets to someone that you *know* does not want them, and then ignoring their response packets? That may be either impolite or criminal depending on your local laws. In any case, it is much easier to simply reconfigure your mail server to not use blackholes.us.

"IPv6 is a fix for this, because the IP addresses don't need to be repeated because there's so many, so *nobody* should get them reallocated to them."

Yes, that might help in general, but not in this specific case, since the glue records are ipv4 addresses. It will be a *long* time before you can run a domain with *only* ipv6 addresses for the dns and mail servers.

And who is to say that the Brett Glass  –  Oct 14, 2009 12:44 PM PST

And who is to say that the blackilst mentioned in this article (which is really a self-serving advertisement) will not one day be a "zombie" too?

If our lists were to go away J.D. Falk  –  Oct 14, 2009 12:50 PM PST

If our lists were to go away some day, we'd close 'em in accordance with the best practices described above.  Or were you trying to be funny?

To post comments, please login or create an account.

Related Blogs

Related News

Other Topics

Access Providers Broadband Censorship Cloud Computing Cyberattack Cybercrime Cybersquatting Data Center DNS DNSSEC Domain Names Domain Registries Email Enum ICANN Internet Governance Internet Protocol IP Addressing IPTV IPv6 Law Malware Mobile Multilinguism Net Neutrality P2P Policy & Regulation Privacy Regional Registries Security Spam Telecom Top-Level Domains VoIP Web White Space Whois Wireless



Industry Updates – Sponsored Posts

ICANN and Cybersecurity: Hot Topics at The First Ever .ORG Forum

Neustar Releases UltraDNS Report Center

Paid Search Ads Can Lead to Fake Goods

Neustar Launches Initiative to Enhance DNS With Faster, More Secure Updates

Open Phishing Season

Nominum Announces "DNSSEC Made Easy" Solutions

.ORG Highlighted for Success in Fighting Phishing

Afilias' Matt Pounsett Elected Director-at-Large for DNS-OARC

.ORG Wins WebAward for Website Redesign and Selected as a Finalist for the NonProfit PR Awards

NeuStar Expands UltraDNS Network Infrastructure in Europe

Nominum CEO: Commercial vs. Open Source - Let Customers Choose

Nominum Broadens Intelligent DNS Impact With SKYE Cloud Services

Afilias Managed DNS Services Adds SiteCertain to Keep Watch on Your Web Site

DNSstuff.com Launches Industry's First Mail Server Test Center

Afilias Seeks New TLD Partners

Growing Global Adoption of Nominum's Intelligent DNS Spells Obsolescence for Legacy DNS Systems

Nominum's Intelligent DNS Gives Service Providers Commanding Advantage Against Internet Threats

ISC, Afilias and Neustar Bring DNSSEC One Step Closer

Afilias Secures Millions of Internet Domains from BIND 9 Vulnerability with DNS Diversity Strategy

Nominum Delivers Service Provider Compliance Solution For Blocking Child Exploitation Sites Online