How DNSBLs Work
Ff you’ve dealt with email for any longer than 5 minutes (as an administrator), you already know it’s a mess. There’s so many security measures, so many checks, so many things to combat bad actors and spam. What if we had some way to have some service publish a list of bad DPs, and mail servers could quickly check that mid-transaction so they can have up-to-date information as to if the in-flight message should actually be accepted or not?
Well, we have exactly that. Enter: the DNS Blacklist.
A word before we begin
Known as a DNSBL or RBL (Realtime BlackList) on the ‘bad’ side, and DNSWL or RWL (DNS / Realtime WhiteList) on the ‘good’ side, this is a special way of structuring a DNS server to serve information on requested IP addresses. Yes, of course we’re using DNS, why not?!
They work in a similar manner to reverse-DNS lookups: You reverse the order of the IP octets, and query that as a subdomain of of the DNSBL in question.
For example, to check the IP address 1.2.4.8 against the my-test-bl.org list, you’d make a standard query (A record) for 8.4.2.1.my-bl-test.org.
If the address is not listed, then the server should return an NXDOMAIN (Non-eXistent domain) error code.
if the address is listed, you’ll get an address back.
Conventionally, 127.0.0.2 is the IP that indicates a generic block, but other IPs in the 127.0.0.0/8 block can be used for specific reasons for your particular list, there’s no real standardization here.1
Additionally, querying for a TXT record on most major lists either gives a reason as to why the code was returned, or a link to their lookup site where you can see details on the queried IP.
The thing about DNS is that it’s designed to be fast. Many MTAs like Postfix, Exim, and the like, can be given a list of lists to query mid-transaction with the client IP. DNS requests can also be sent in parallel, meaning that it shouldn’t take more than a second or two for all your results to come back.
Controversy
There’s a bit of controversy around the concept and usage of such lists, partially because in the past, operators of such have been the target of Denial-of-Service attacks, as well as the fact that unless you’re using some weighted approach to scanning multiple lists, most MTAs only need one listing to reject a client. Thus, a list operator who isn’t exactly neutral has almost unchecked power to (un)list whatever addresses they like. Until people notice, and word is spread that said list shouldn’t be trusted, they could realistically do whatever they wish. Additionally, blocking just by IP can cause legitimate email to get caught in the filter too, especially on shared IPs. And besides all that, procedures for (de)listing aren’t always clear, nor handled quickly. For example, one list that Yandex uses (Which results in them blocking my DMARC reports for their spam, which I find way too hilarious) requires that you send an email from the registered rDNS name of your server’s IP, which that list is all too happy to tell you has no MXes and isn’t possible, have fun being blocked with no way to explain yourself.
Now I make a lot of references to using DNSBLs for email here, but that’s only the primary use. Really, it’s just a, well, blacklist that can be queried in real time. If I wanted, I could block a login page on my website with a DNSBL check, there’s nothing stopping me (well, maybe besides server support, but it could still be done in theory). But, because email is such a huge target for spammers and attackers, having the ability to preemptively know you’re going to reject a connection, sometimes before they can send their first line of SMTP, is something that’s welcomed.
Running One
Why? Well, I’m not writing this on the assumption you want to run your own DNSBL, I’m writing this as an example of how stupidly simple one is to set up. Really, there’s nothing special, just put a DNS server on a (sub)domain and feed it full of records for IPs that you want to block. It’s nothing special. It’s just DNS.