On Tuesday 28 September 2010, Netregistry was caught up in an incredibly large Distributed Denial of Service (DDoS) attack that attempted to target AFACT.org.au. In reality, those participating in the attack were targeting a Netregistry hosting cluster, causing the hosting infrastructure difficulty in maintaining service.

For more detail on the reasons for the DDoS attack and Netregistry’s response, read Post-mortem: How the DDoS attack on AFACT misfired at ITNews.com.au.

DDoS attacks are common enough across the internet, where groups attempt to push a website offline by flooding it with requests for data. This is designed to overload the server, causing it to crash. DDoS attacks have previously been targeted at government departments, Facebook, Twitter and many other high profile sites.

By their very nature, DDoS attacks represent a flood of data requests far out of proportion with what would naturally be expected. It is this spike which causes the problems. But for many websites, a purely innocent – albeit much smaller – spike can be enough to knock a website offline.

Sometimes called the Digg effect, or Slashdot effect, a sudden spike in traffic can be caused purely by being popular. If a blog post is shared in major communities like Digg, for example, or if a sales promotion attracts a lot of interest, the rise in traffic can sometimes cause problems if your hosting service isn’t prepared for it.

This happened to Threadless in 2009 when a sale offer was circulated by them on Twitter, only to attract so much traffic that the website stopped responding. This is why many businesses now opt for either a dedicated hosting server (or a network of clustered servers) or opt for shared hosting on a Cloud infrastructure.

A Cloud hosting infrastructure – similar to that pioneered by Netregistry in 1999 – shares the load across a vast number of servers. If one particular server is experiencing higher than normal traffic, the overflow is shared amongst other servers via load balancers. This means that all websites on the server array have access to a massive amount of resources so even a spike in traffic won’t result in any deterioration of performance.

This differs from many shared hosting servers which merely host websites confined to individual servers. If one website on that server experiences a spike in traffic, all the websites on that single server are also affected – sometimes pushed offline. And the resources available to that single server are also far less than those available to a Cloud infrastructure – meaning a much, much smaller spike can push that server offline and all the websites hosted on it.

However, a DDoS attack, such as occurred on Tuesday, can dwarf a natural spike as it attempts to defeat the server. Tuesday’s attack was one of only three attacks on such a scale to have affected Netregistry’s services in over ten years. However, the Cloud infrastructure meant that no server was knocked offline – with the increased load shared amongst the entire array.

At its height, the attack directed 60,000 active http connections and 100 megabytes per second of additional bandwidth at the server cluster containing the AFACT website. When you consider that the average hosting account at Netregistry doesn’t exceed 20GB of data transfer in a month, the spike saw the same amount of data being transferred every three minutes.

Such a massive spike in activity naturally saw some degradation of performance across the hosting infrastructure. This resulted in many websites experiencing intermittent connection issues and slowed performance. Email delivery was also delayed, although no data was lost. However, at no time were servers knocked offline, reducing the potential effect of the attack significantly.

It took an attack of this magnitude for performance to be affected on Netregistry’s Cloud hosting infrastructure – an extremely rare occurrence. Although some businesses experienced inconvenience during this period, the DDoS attack demonstrated the level of interference required before the hosting service would suffer problems – many, many times what would be expected from natural usage.