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.)

By J.D. Falk, Internet Standards and Governance. More blog posts from J.D. Falk can also be read here.

Related topics: DNS, Email, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

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

"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 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... wolfkeeper  –  Oct 13, 2009 11:52 AM PDT

...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 9:26 PM PDT

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 wolfkeeper  –  Oct 13, 2009 9:51 PM PDT

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 1:00 PM PDT

"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 1:44 PM PDT

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 1:50 PM PDT

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

Topics

Industry Updates – Sponsored Posts

Nominum Announces Future Ready DNS

Non-English "IDN Email" Addresses Are Finally Working!

Dyn Acquires Internet Intelligence Company, Renesys

Introducing getdns: a Modern, Extensible, Open Source API for the DNS

Why We Decided to Stop Offering Free Accounts

Tony Kirsch Announced As Head of Global Consulting of ARI Registry Services

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

Dyn Acquires Managed DNS Provider Nettica

Why Managed DNS Means Secure DNS

SPECIAL: Video Interviews from NamesCon 2014 in Las Vegas

Rodney Joffe on Why DNS Has Become a Favorite Attack Vector

Motivated to Solve Problems at Verisign

Dyn Announces Largest Quarter In Company History

Diversity, Openness and vBSDcon 2013

How Does Dyn Deliver on Powering the Internet? By Investing in Standards Organizations Like the IETF

Neustar's Proposal for New gTLD Collision Risk Mitigation

Dyn Announces the Opening of New Data Center in Mumbai, India

15 Facts About .net to Celebrate 15 Million Registrations

SPECIAL: Updates from the ICANN Meetings in Durban

Dyn Building a Lineup of Technical Talent

Sponsored Topics