Linode reckons its long outage has come to an end, although its most-current message says there may be “intermittent” issues for users, mostly of its Atlanta facility.

At the time of writing, the status of all services was listed as “operational”, except for Atlanta which still shows as “partial outage”.

The company has been the target of a heavy and sustained denial-of-service (DoS) attack that began on Christmas Day.

Under criticism for its initial silence about the issue, on New Year's Eve the company offered this extensive post from a network engineer, Alex Forster. In it, Forster details just how many of the company's systems were under attack. There were:

High-volume attacks on its DNS infrastructure;

The same against “all of our public-facing Websites”, knocking out Linode Manager;

“400 bad request” attacks on the same Websites, again hitting Linode Manager;

DoS against Linode's colocation provider “overwhelming the router control planes and causing significant congestion/packet loss”;

The same against Linode's own network infrastructure.

At the time of the post, Forster wrote, there had been 30 “significant” attacks, and each time the company closed a vector, the attackers switched vectors.

Promising a detailed technical explanation once the attacks stop, Forster says: “We would like to apologize for the lack of detail in some of our recent status-page updates. Please know that we are dedicating all resources from multiple departments to stopping these attacks.”

As Linode's status page states, the company has had to send many regions in the world to /dev/null (so to speak) to keep its systems alive:

“For the short term, we will be using BGP communities to attempt to block Asia Pacific, the Middle East, South America, and others, hopefully leaving us only with traffic from North America and Western Europe. Blocking geographic regions this way is the only way to make sure that large botnets won't be able to launch further attacks.”

With Atlanta more-or-less sorted, there was another brief attack on its DNS, from 21:01 UTC on January 3 to just after midnight. ®