Presumably the point here would be to either intercept the messages in flight or change content. Of course the receiving mail handler will get the HELO message from this weird inter-modal relay. One wonders if there is a need for keep a list of validated relays. As the attack is not continuous, it should be possible to track final received-from headers in the messages to identify periods where the system was potentially mis-behaving.
It is also possible that people do maintenance on servers and move the MX record around to keep traffic off the server while they are working on it.
The step to go beyond that, of course, would be to use DANE with the SMTP connections so that the entire mail exchange could happen over TLS and using certs that have been validated via DNSSEC/DANE. But first step is to get the MX records signed and to have DNS resolvers validating that fact.
The article expresses surprise that traffic is diverted to IP addresses in Google's IP block. Could nefarious types be using BGP to temporarily take over a small block of IP addresses here, as described in https://news.ycombinator.com/item?id=8263391 ?
DNSCurve + MinimaLT would completely stop these attacks. Based on public statements and hackathon reports I think MinimaLT will be released this semester (development is coordinated from rites.uic.edu).
I'd say it is not very common, but there are obviously some deployments out there.
Mandatory example: $ dig yp.to ns
I think it's sad that the trend is towards DNSSEC which provides not confidentiality, only authentication. As we've seen since last summer, the extra protection is very much needed.
Less than 1% of domains under .com are DNSSEC-signed, and many of them are long-term failing. At this point, 20 years after work began on DNSSEC, it's time to move on.
This is what the world in production looks like. Things may move at a glacial pace but that's because there is a steady stream of real world issues to iron out.
Even if you started work on a superiour alternative today, expect to keep working on it for the better part of a decade before you see any real world uptake.
Not even IP itself did conquer the world overnight.
Meanwhile, 85% of .GOV domains are DNSSEC-signed as are 34% of .NL domains and 18% of .BR. The improved security of DNS via DNSSEC is happening... it's just unevenly distributed.
Which is funny because the US Congress passed a law mandating DNSSEC for .gov domains. Not to mention the many outages, plus non-deployments, where domains CNAME to a non-DNSSEC CDN.
34% of .NL domains
That's because it's common for .nl domain owners to essentially be paid to run DNSSEC. That's how bad it is.
Actually, I do run DNSSEC on most of my domains, but for that particular one, danyork.com, I unfortunately lost DNSSEC support when I needed to switch the name servers to CloudFlare to be able to essentially have a CNAME at the apex (using what CloudFlare calls their "flattening" service).
Longer story... but the good news (for me) is that CloudFlare has publicly said they will be providing DNSSEC signing for their CDN by the end of 2014... so in theory I should be back to having that domain signed within the next few months.
FYI, CloudFlare's slides from the ICANN presentation where they talked about this are at: http://t.co/34sAH1FVLB
It is also possible that people do maintenance on servers and move the MX record around to keep traffic off the server while they are working on it.