DNSBLs, wildcards and domain expiration

Last week the megarbl.net domain name expired. Normally this would have no affect on anyone, but their domain registrar put in a wildcard DNS entry. Because of how DNSBLs work, this had the effect of causing every IP to be listed on the blocklist. The domain is now active and the listings due to the DNS wildcard are removed.

How does a domain expiration lead to a DNSBL listing the whole internet?

Well, it’s kinda complicated and involves some of those grubby corners where different things that shouldn’t happen all occur and weird stuff happens.

But I thought there were rules and standards about this stuff.

Well, there are standards on the Internet. The IETF publishes documents “Request for Comments” (RFCs). These aren’t rules as much as they are standards. While many folks treat RFCs as rules, that’s not really what they’re for. All the RFCs do is tell operators how to do things if they want to communicate seamlessly with other entities.  Not every RFC is a standard; some are informational, some are experimental, some are drafts being actively developed and some are current practices.

So how does a domain expiration lead to listing all IPv4 space on a blocklist?

Well, there are a few technical things we need to understand before we can see how we get from domain expiration to blocklisting.
How DNSBLs work
First we need to talk about how DNSBLs work. DNSBLs publish a list of IP addresses. To query a DNSBL for an IP address you take the IP address, reverse it, add the DNSBL name onto the end and query for that domain.
Let’s say I want to look up  37.49.224.172 on the SBL.  I flip the IP address and add sbl.spamhaus.org to create the domain name 172.224.49.37.sbl.spamhaus.org. Then I do a DNS lookup on the domain name. If the IP is listed, then Spamhaus will return an A record / IP address. If the IP is not listed, then Spamhaus will return an NXDOMAIN and no A record.
All DNSBLs are run this way, so if you get any answer to a DNS query it means the IP is listed. And, yes, this is how blocklists are queried, even when you use a web form. It’s all DNS behind the scenes.
DNS wildcard records
Now that we know how DNSBLs are queried, we need to talk about DNS and wildcarding. Wildcarding is allowed in the DNS RFCs, but it’s complicated. So complicated entire RFCs have been written to try and explain the grubby corners. I’m certainly not going to try and explain it. If you want more details check out the Google support pageIAB commentary on wildcarding or the Wikipedia article.
The short version that works for our purpose is that a wildcard entry in DNS means that there is an IP for every domain queried.  You can make up any domain name and it will return an A record.
Wildcard records and registrars
The next thing we need to know is that some registration providers take unregistered domains and publish wildcard DNS records for them. Typically this is done to collect add revenue for parked or unused domains.

OK… so how does that lead to blocking?

When a domain expires and the registrar reclaims it and publishes a wildcard DNS record, then every query to the DNSBL will come back positive. The only negative DNSBL response is “NXDOMAIN” so the presence of any A record is a listing.
Expiration_Listing

That shouldn’t happen…

Well, no one is technically doing anything wrong here, except possibly the registrar by publishing wildcard record for expired domains. Or the domain owner by forgetting to renew their domain in a timely fashion. The good news is that it happens very rarely, typically once you lose a domain due to expiration you figure out how not to do that again. And not all registrars wildcard expired domains. This is just one of those things where no one is doing anything wrong or unusual, but when they all happen together unexpected things happen.
The good news is that, as of today, the domain is back and the false listings are removed.

Can a DNSBL stop this from happening?

There are number of ways a DNSBL can stop this from happening. The two big ones are not to let the domains expire and use a registrar that won’t wildcard parked domains. Other than that, though, they can’t really.

I’m a DNSBL user, how can I know this is happening?

Well run IPv4 DNSBLs should always list 127.0.0.2 and should never list 127.0.0.1. DNSBL users should query a DNSBL daily for these two addresses. If it is listing 127.0.0.1 or it is not listing 127.0.0.2 then it should be considered non functional and dropped from your filtering scheme. (RFC5782 and RFC6471, )

Related Posts

The Internet is hard.

There are so many things that need to happen to make the Internet work. DNS entries need to be right. MXs need to be set up. Web servers need to be configured. And, let’s be honest, anyone who has ever run their own services on the Internet has flubbed a configuration.
We don’t think about it, because most of the time the configurations are handled by scripts and they do things right. But at some point someone needs to type in something and there’s a risk it will go horribly wrong. I’ve been digging into domain data for a client of mine today. I think I’m going cross-eyed over it. But I have found so many weird things that just mean someone isn’t paying attention to what they’re doing.
Like the domain that has a MX record that says:
nullmx
 
I’m pretty sure the intention of the domain owner is to publish a null MX. But they added an extraneous “0” in there and ended up publishing something really weird. Even worse, the MTA that this client is using is listing this as a “delivered” email. I’m pretty sure that mail to that domain never left the MTA.
I’ve found horribly typoed MX domains for popular spam filters. I’ve found domains that have invalid characters in them. I’ve found domains that are totally a mess.
The vast majority of us have some story or other of the time we really broke things by accident. Like the time a very large ISP deleted their MX records. Or when a different ISP changed their internal forwarding and broke SPF authentication for everyone mailing that domain. Or when another ISP accidentally blocked every IP beginning with 6.
Sometimes I’m amazed that the Internet ever works. No matter how big it gets, there are actual people writing actual code and configurations. The number of things that have to happen to get packets from A to B is pretty impressive. We rarely ever notice the breakages, the people who run things are really good at their jobs. But sometimes poking in the grotty corners reminds me how easy it is to break things. It’s sometimes a wonder things actually work.
 

Read More

HE.net DNS problems

Hurricane Electric had a significant outage of their authoritative DNS servers this morning, causing them to return valid responses with no results for all(?) queries. This will have caused delivery problems for any mail going to domains using HE.net DNS – which will include some of their colocation customers, as well as users of their free services – but also will have caused reverse DNS to fail for most servers hosted by Hurricane Electric worldwide, so if any of your mail is being sent from HE hosted machines you may have seen problems.
(We’re HE customers so we noticed. Still happy with them as a vendor.)

Read More

TXTing

txt
On Friday I talked a bit about the history behind TXT records, their uses and abuses.
But what’s in a TXT record? How is it used? When and where should you use them?
Here’s what you get if you query for the TXT records for exacttarget.com from a unix or OS X command line with dig exacttarget.com txt

Read More