Anycast - Three Reasons Why Your DNS Network Should Use It
On October 21, 2002, the Internet’s core root server system as a whole came under a significant attack. A coordinated distributed denial-of-service attack aimed to knock the 13 domain name system root servers – the closest thing the Internet has to a single point of failure – offline. Had it succeeded, electronic communications would have eventually frozen up and e-commerce would have slowly ground to a halt. The economic consequences could have been dire.
Happily, thanks to the foresight of the root server operators, the DDoS failed to muster up sufficient attack traffic to achieve its objectives. But it did make the DNS community realize that it would have to take even more precautions to thwart future attacks.1 The key conclusion, drawn in the aftermath, was that the root servers needed to be mirrored more widely, to spread the risk footprint across a wider area, using a technology known as Anycast.
Anycast allows multiple, identical, globally deployed DNS servers to advertize the same IP address. For all intents and purposes, the same server exists in dozens or hundreds of places simultaneously. When an Internet user looks up your domain name, they find the Anycast instance topologically closest to themselves. Usually, there's a correlation between network topology and physical geography. A user in Madrid might find and use a node in London or Amsterdam, while a user in Mexico might find themselves directed to a node in California.
Five years after that root server attack, in February 2007, a second large-scale DDoS was launched on the same targets. It was ten times larger and lasted almost ten times longer than the 2002 attack. This time, the attackers had some small success. While the system as a whole once again proved its resilience, the attack did manage to impair the performance of two of the 13 root servers.2
Crucially, the two affected servers were found to be the only ones to have NOT implemented Anycast in the intervening years. That was deliberate; at the time, it was seen in some quarters as too immature a technology to be deployed ubiquitously across such an important resource. But the point was proven: Anycast mirroring of DNS services is a very good way of ensuring reliability under even the most trying of circumstances.
The learning for today’s environment where virtually every type of business depends upon the availability of the Internet, is that it's not just the root servers that can benefit from Anycast. Now, not only are all the major top-level domains (TLD) deployed using Anycast, but many companies have found they can leverage an Anycast architecture to improve the security and reliability of their Internet presence as a whole.
Anycast makes DNS more reliable
When you deploy identical servers at multiple nodes, on multiple networks, in widely diverse geographical locations, all using Anycast, you're effectively adding global load-balancing functionality to your DNS service. Importantly, the load-balancing logic is completely invisible to the DNS servers; it's moved down the stack from the application to the network layer. Because each node advertises the same IP address, user traffic is shared between servers globally, handled transparently by the network itself using standard BGP routing.
This also means that an Anycast DNS service has failover baked in. If a node is removed or taken offline, whether for routine maintenance or due to more nefarious reasons, it ceases to advertise its shared IP address and upstream routing tables will no longer send DNS queries to the offline node. Because another Anycast instance of the server will still be available, maybe just a hop or two away, end users see no interruption in their service.
Anycast improves DNS performance
On the Web, having a fast site is not only a user experience issue. Now, the speed with which pages load is even alleged to be used as a factor in search engine rankings. Naturally, anything an organization can do to improve performance is desirable, and Anycast can help towards that objective.
By allowing clients to reach the DNS server closest to them, the latency associated with multiple hops can be reduced and potential network bottlenecks between the user and the name server become irrelevant. If there's an Anycast resolver node hosted at the DNS client's nearest large Internet exchange, there's no need for their query to make an intercontinental round-trip before it can get on with the important business of pulling down Web pages.
Anycast provides resilience against DDoS attacks
While distributed denial of service attacks are, as the name suggests, distributed, the botnets used to launch the attacks tend not to be distributed evenly. Malware, with which “bots” infect end user PCs, is often designed for specific regions or users of specific languages, and botnets are often clustered to reflect that. The 2007 root server attack, for example, saw most of its traffic originating in Asia-Pacific.
More recently, the “Mariposa” botnet, which was shut down in late 2009, has been cited as having more than 12 million IP addresses associated with it, but over half of those addresses belonged to networks in just five countries: India, Mexico, Brazil, Korea and Colombia.3 If an organization were to come under attack by Mariposa and it had broadly deployed Anycast-enabled DNS nodes, it could have seen some locations absorb the brunt of the attack. A node deployed to a network in India, for example, may have been able to accommodate almost a fifth of the unwanted traffic, preserving the rest of the infrastructure to still successfully answer queries from real users in the rest of the world.
Of course, designing and rolling out an Anycast DNS network is not a trivial task. The complexities associated with managing servers in multiple locations are obvious. As with any system design decision, the trade-off between availability and cost has to be discussed. But, as the managers of the Internet's most crucial addressing resources have found, Anycast should be an important part of the cost-benefit discussions you have when you proclaim your web site open for business on the DNS.
1 Vixie, Paul; Gerry Sneeringer, Mark Schleifer (2002-11-24). "Events of 21-Oct-2002". http://d.root-servers.org/october21.txt. Retrieved 2008-07-11.
2 ICANN, http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf
3 Panda Labs, http://pandalabs.pandasecurity.com/mariposa-stats/
