Want a great example of why we need DNSSEC now? Consider this new research from the CERT/CC team at Carnegie Mellon University that finds that someone is hijacking email messages to relay them through another email server. The messages are being delivered, but it’s unknown whether they are being modified before delivery or simply logged and monitored. As they say:
The disconcerting aspect of this work is not how many domains we see being poisoned, as there are relatively few, but which domains they are. We observe changes in A records so that a domain resolves to a different IP address. But the domains being targeted are often listed as name servers or mail exchanges for other domains. The biggest free webmail providers have been repeatedly victimized on some unknown (but likely smaller) subsection of the Internet sometime during the last year.
Someone… or multiple entities… appear to be poisoning DNS caches so that they can interject their own mail server into the delivery path of the email messages. The CERT/CC team goes on to explain the attack and provides a very useful diagram:
Figure 2 diagrams how this usual process can be thwarted if the DNS answer for the IP address of the destination MX is changed. The mail message makes an unintended pit stop at the poisonous IP address. That server can then forward the message to its intended destination. Since mail is transmitted asynchronously, the sender and recipient are not likely to notice anything out of the ordinary. The sending IP address in the message header would likely reflect the diversion, but since mail handling often has a few exchanges before the final destination, it is not immediately obvious to anyone along the path that the diversion was out of the ordinary.
They go on to outline the potential outcome of the attack:
Unless the whole message is cryptographically protected, the intermediate server can read and modify the message, or append malicious content. This attack would defeat opportunistic TLS encryption between MXs that is meant to ensure the confidentiality of messages in transit. And there are some small changes the intermediary could make to the mail that would make the attack worthwhile, such as changing a bank account number for a home purchase deposit.
Essentially, the attacker could do anything they want with the email message as it is now in their possession, including:
- Modify the message to either add, change or remove content
- Log the message (and all of its content) in some large database
- Simply drop the message (i.e. don’t deliver it) so that the recipient never gets the message
The researchers don’t yet know who is behind this redirection. It could be:
- Criminals
- Nation states (ex. intelligence agencies)
- Other security researchers
All they know is someone is hijacking delivery of email messages for some reason – and they are seeking help from the larger Internet community! (Please see the bottom of their post.)
How To Protect Your Email Delivery
As the researchers note, DNSSEC is designed to prevent this type of hijacking of DNS information. This type of hijacking would be prevented if:
1. The recipient’s domain name was signed with DNSSEC which means that the MX records (and all other DNS records) would have a cryptographic signature added.
2. The sender’s local DNS resolver was performing DNSSEC validation in which it checked the DNSSEC signatures.
Had this been in place, then the sending mail server would not have received the false MX record and would not have delivered the email to the attacker’s server. You can read more in our document about the two sides of DNSSEC.
This hijacking of email messages is going on right now on an ongoing basis according to the researchers, and so you can take two steps to ensure that your email messages are not being hijacked:
1. Sign Your Domain With DNSSEC
The first step is to sign your domain with DNSSEC so that your MX records are protected. If you do not operate your own DNS servers, this may involve you contacting your DNS hosting provider or DNS registrar to ask them to perform DNSSEC-signing on your domain. We have some information about how to do this here:
and ICANN has a list of some of the registrars that provide some degree of DNSSEC support.
If you do operate your own authoritative name servers for your domain, then you can determine what you need to do to sign the domain with DNSSEC. Many of the common authoritative name servers such as BIND, NSD, Knot and Microsoft Windows Server 2012 all include support now for DNSSEC signing. There are also additional tools such as OpenDNSSEC that can help make this work smoothly. Some of the resources that may help:
Once you have signed your domain, you will then need to communicate your “DS record” to your parent zone (often the top-level domain) by way of your registrar. See our page about working with registrars for more information.
2. Turn On DNSSEC Validation On Your Network
With signing, inbound email messages to you will not be hijacked (assuming the sender is performing DNSSEC validation), but the possibility will still exist for outbound messages you send to be hijacked if your mail server doesn’t learn the correct address for the recipient’s mail server.
To enable this layer of protection, all you need to do is turn on DNSSEC validation on your local DNS server – or whatever DNS resolver your email server uses. That is the important part because in this instance we are trying to protect email delivery. You want your email server to be getting the correct DNS information.
We wrote about how to do this and recommend an excellent whitepaper from SURFnet that explains how to easily do this with three of the common DNS resolvers: BIND, Unbound and Microsoft Windows Server.
Now… if you don’t control the local DNS server – for instance, if you use the DNS resolver at your local Internet service provider (ISP) – then you need to contact that organization to find out if they can enable DNSSEC validation.
If your ISP is unwilling/unable to turn on DNSSEC validation, you could set your mail server to use external DNS servers that perform DNSSEC validation such as Google’s Public DNS, but we don’t recommend this unless it is your last resort because using such a distant DNS server provides a lot of room for an attacker to still inject fake packets. As we wrote about in our “plan for DNSSEC validation“, the ideal is to have the DNSSEC validation happening as close as possible to the mail server (in this case). It would be much safer, and perhaps quite easy, to install a local DNSSEC-validating resolver on or near your mail server itself.
With those two steps, you will protect the delivery of email to your domains – and protect your mailserver from delivering email to whomever is out there right now hijacking all these messages.
Let’s do that today, okay? If we all do it now we can make the Internet that much safer and more secure!
If you’d like more information about DNSSEC, please see our “Start Here” page to find resources tailored to your type of organization and role – and please let us know if you need even more information!
