It came to my attention recently that there are some cloud-based recursive DNS services that don’t permit you to block MX records. Of course, I don’t mean “block the resolution of all MX records,” since resolving MX records is a requirement for sending mail over the Internet. But they don’t allow you to create policies to block specific MX records. That seems silly—and potentially dangerous—to me, given the possibility of MX-record abuse by the bad guys
Let’s start with the MX record’s primary function: Determining where to send email that’s addressed to a particular domain name. MX records provide a level of indirection, allowing an administrator to specify one or more mail exchangers for a particular domain name. In the modern Internet era, that’s critical, because so many organizations use big email providers such as Gmail and Outlook.com. These organizations can preserve their identity—for example, user@infoblox.com addresses–while one of these providers manages their email servers. That might look like:
Which redirects email addressed to users@nxdomain.com to Google’s mail servers.
But what about the bad guys, people who send spam or, worse, mount phishing campaigns? In those cases, you may well want to prevent the resolution of the domain names that own the MX records, not the shared email infrastructure they use.1 This selective blocking would prevent users from inadvertently replying to spam or phishing email, or clicking on mailto: URLs in the messages that point to those domain names. But preventing the resolution of the names of the mail exchangers might be “tarring them with the same brush,” and could cause collateral damage by keeping you from sending mail to legitimate domain names that use the same infrastructure. Imagine a larger set of MX records that look like this:
In this example, nxdomain.com (which is my personal domain) and spammer.com (which apparently is for sale!) share the same set of mail exchangers, so blocking the resolution of spammer.com’s mail exchangers (in this case, aspmx.l.google.com and friends) also prevents people from sending mail to nxdomain.com addresses. Not cool! (For the record, with Infoblox’s BloxOne Threat Defense or with RPZs plumbed into our appliances, blocking spammer.com blocks MX records along with all other record types.)
“But wait,” some of you may be thinking. “I have an email gateway or service that protects me from spam!” Perhaps even more disconcerting than spam is the threat of using MX records to tunnel data. While other record types such as TXT records can carry larger payloads, MX records can carry plenty (a 256-character domain name plus a 16-bit preference) and, as we’ve heard, have the benefit that some people think they’re innocuous. Bad actors who know that some services lack the ability to block MX records might choose to use them just for that reason.
Similarly, MX records could be used in a Domain Generation Algorithm (DGAs) to enable malware to rendezvous with a command and control server. From the threat actor’s perspective, one advantage is that most DGAs use A or AAAA queries, so a DGA’s use of MX records would be unexpected.
Given all these considerations, when asking whether a recursive DNS service should be able to selectively block MX records, my response is, “Why not?”
Endnotes
- To be sure, many spam and phish senders use their own, dedicated email infrastructure, but not all do.
