If you live for tech news and/or you’re relatively active on Twitter, you likely heard about some DNS issues that Twitter, the New York Times and other sites went through due to an alleged attack by the Syrian Electronic Army. Despite what some may assume amidst a competitive environment, these are heartbreaking and maddening situations for those of us that live DNS and Internet performance.
Since Dyn clients were affected — including Twitter — we are being asked about whether our systems have been compromised and if there should be concerns about services. They haven’t been and there shouldn’t be. But I can’t stress enough: the point of this post isn’t to point fingers or attempt to swing a competitive balance our way. Rather, it’s to help educate about a different portion of the global DNS that we don’t run.
These issues happen and unfortunately, much more frequently than we like to hear about. Like you, we’re a fan of the Internet in all of its evolving glory. We hate downtime, regardless of what company people use. Having said all that, here’s an explanation that will hopefully be educational as news continues to develop on this situation.
There are three common ways to redirect traffic through compromised DNS.
The first way is to perform a cache poisoning attack.
Basically, attackers attempt to inject malicious DNS data into the recursive DNS servers that are operated by many ISPs. These DNS servers are typically the “closest” to users from a network topology perspective, so the damage is localized to specific users connecting to those servers.
There are effective workarounds to make this impractical in the wild, and good standards like DNSSEC that provide additional protection from this type of attack. This was not at play here.
The second way is to take over one or more authoritative DNS servers for a domain, and change the DNS data.
This is the type of service that Dyn runs for clients like Twitter. If an attacker were to compromise authoritative DNS, the effect would be global, and good security practices like strong passwords, IP ACLs (acceptable client lists), and good social engineering training are effective at thwarting these attacks. This was not at play here.
The third way can be the most difficult to undo, and that is to take over the registration of a domain and change the authoritative DNS servers.
That’s what happened here in this attack. For the affected sites, the attackers gained access to the domain registration accounts that were operated by Melbourne IT, and changed the authoritative DNS servers to ns1.syrianelectronicarmy.com and ns2.syrianelectronicarmy.com. At this time, those authoritative nameservers answered all queries for the affected domains. What makes this attack so dangerous is what’s called the TTL (time to live). Changes of this nature are globally cached on recursive DNS servers for typically 86,400 seconds, or a full day. Unless operators are able to purge caches, it can take an entire day (sometimes longer) for the effects to be reversed.
So now what?
We are doing everything we can to support those affected by this attack, and are making doubly certain our own staff are on high alert in the event attackers attempt to compromise a Dyn system. Our industry is a tight group of global recursive, authoritative, and domain registrar operators, and we stand together to help one another.
To be clear, all of the information here is publicly available knowledge that can be gathered via DNS and whois queries. Also to be clear, there are three layers to the hierarchy here from a technology perspective: the recursive DNS, the authoritative DNS, and the domain registration. Dyn provides authoritative services, and this was an attack on the domain registration itself. The Dyn systems were not compromised.
For my fellow operators that are actively combatting the situation, we’re here for you for whatever you need.