I have often remarked that any fool can run a DNS-Based Blacklist (DNSBL) and many fools do so. Since approximately nobody uses the incompetently run black lists, they don’t matter. Unfortunately, using a DNSBL requires equally little expertise, which becomes a problem when an operator wants to shut down a list.

When someone sets up a mail server (which we’ll call an MTA for Mail Transfer Agent), one of the tasks is to configure the anti-spam features, which invariably involves using DNSBLs. Some software (notably Spamassassin) comes with DNSBLs pre-configured, some require you to choose the ones you’re going to use.

Since most MTA admins are not mail experts, they ask around, find a set of DNSBLs their friends use, put them in the configuration, and forget about it unless something goes so badly wrong that they have to fix it. Once they’re set up, the MTA sends out DNSBL queries for the sending IP address of every incoming message. Depending on the way the MTA is set up, if a DNSBL lists an IP address, the MTA may outright reject the message, or it may use the DNSBL result as part of a scoring system.

The problem arises when one of the DNSBLs wants to shut down. Running one competently is a lot of work, and it’s not surprising that people run out of time, retire, or otherwise can’t do it any more. The goal is to get all of the people who are querying the DNSBL to stop. How do you do that?

The usual first approach is to notify everyone you’ve told about the DNSBL, send mail to lists about mail management, and so forth. Then you list nothing, return NXDOMAIN to every request, for a while. This will cause a small drop in query volume, since none of those systems on autopilot will notice or care.

Eventually desperation sets in, as the queries just keep rolling in. I run a small DNSBL (korea.services.net) and although I have no plans to shut it down, I can see from the query logs that some system admins can’t type, and are querying kroea.services.net, or in one case http://korea.services.net, with a colon and slashes in the domain name. I would prefer that if they want to query my DNSBL, they query the actual DNSBL, so I’ve tried various techniques to get their attention. I’ve introduced very long delays, or used DNS delegation to point to name servers that don’t exist on networks that don’t exist. These should cause very slow responses on the mail servers, which you’d think that someone might notice and investigate. Nope.

The final step is to put in a wildcard to list the world, answer every query saying that the address is listed. This is somewhat controversial. RFC 6471 on Overview of Best Email DNS-Based List (DNSBL) Operational Practices says not to do it, on the theory that it will cause needless disruption. I used to agree, but now I’m thinking that we need to force those dusty mail systems to fix their software so they’ll automatically stop using dead DNSBLs. I put in wildcards for those misspelled korea names several years ago, and also returned deliberately insulting TXT messages that might appear in their logs, e.g. “your mail has been rejected due to sheer incompetence.” The abandonware is hammering as hard as ever.

The AHBL list, a widely used list for over a decade, was shut down last year. Predictably, the queries continued to hammer on their web server even though nobody was getting any useful responses, so in exasperation they listed the world last week to try and get the queries to stop. As far as I know, it didn’t help much either.

The solution is to automate the client side of shutting down a DNSBL. It is not hard to tell whether a DNSBL is operating. By long tradition, every list contains a test entry for address 127.0.0.2, and does not have an entry for 127.0.0.1. At least since I wrote RFC 5782, on DNS Blacklists and Whitelists, a similar convention for DNSBLs that handle domain names rather than addresses is that the name TEST is listed and INVALID is not.

A client MTA can check the two addresses, and if it gets the desired response and not the undesired one, the list is operating. If it gets neither or it gets both, the list is dead. This catches both DNSBLs that are shut down and don’t respond at all, DNSBLs that deliberately list the world, and the common case that a list is abandoned, its domain name registration expires, and is then picked up by a speculator that sets up wildcard DNS pointing to a “for sale” page.

The wildcard looks enough like listing the world to confuse a lot of people. For example, I recently saw complaints about this page which claims that a provider uses defunct DNSBLs called webmail.rhs.mailpolice.com and dynamic.rhs.mailpolice.com. The mailpolice.com domain is owned by a speculator with wildcard DNS and a for-sale page. A few moments’ thought should confirm that nobody can be using it to block incoming mail, since if they were, they’d get no incoming mail at all. Nonetheless, someone was sure that they were listed and it needed to be fixed, now.

What needs to be fixed is all those abandonware MTAs. (I realize this is not going to be easy.) If spam filters checked their DNSBLs once a week, and didn’t use the ones that failed the check, that would both relieve the load on the nameservers of dead DNSBLs, and it would make the MTAs work better and faster, since they would not be wasting time asking DNSBL questions to which they will never get useful answers. I suppose I can start by sending in patches for Spamassassin.