If you read the online version of The New York Times cover to cover, Tuesday was a weird day for you.

An unprecedented takedown effort knocked the news outlet’s home page offline for most of the afternoon and evening, and users still reported problems logging onto the site as late as this morning. Similarly, Twitter’s image server went down for a short period Tuesday evening.

While your association may not be a political target like those two media giants, the method used is a realistic threat if you own a website—and one you should protect yourself from. More details:

How the attack worked: The attacks, suspected to be the work of the Syrian Electronic Army (backers of Syrian President Bashar al-Assad), relied on unauthorized access to domain name records, which were then modified to go to alternate locations. (The attacker was able to get into the DNS provider for both the Times and Twitter, MelbourneIT, through a reseller.) In the Times’ case, this mostly meant that pages turned up “404 Not Found” errors, but the Twitter hack had the potential to be more serious. Twitter serves up JavaScript code used on many pages across the web; the URL for that JavaScript feasibly could have been replaced with a malicious payload, affecting numerous sites. In the end, though, most users only experienced Twitter’s downtime as a series of broken images on the site.

When I woke up this morning I had no idea I'd be on a video conference with CloudFlare, OpenDNS, Google, GoDaddy, Twitter tech folks all day

— Rajiv Pant राजीव पंत 潘睿哲 (@rajivpant) August 28, 2013

How they fixed it: As Times Chief Technology Officer Rajiv Pant alluded above, the news site and social network worked closely with three companies known for their deep knowledge of domain-related issues—CloudFlare, GoDaddy, and OpenDNS—to restore service. In a post-mortem on the attack, CloudFlare CEO Matthew Prince noted that the companies worked together to clean up the issues, placing a registry lock on NYTimes.com. Some DNS systems, including OpenDNS, made the changes right away. So why did it take so long for the site to come back online? “Unfortunately,” Prince explains, “because recursive DNS servers cache results for a period of time, even after the records were corrected, many name servers were still pointing to the incorrect locations for affected domains.” In other words, not every DNS server works at the same speed.

How you can prevent it: CloudFlare’s Prince offers this advice for high-profile domains with significant security risks: “There is one sensible measure that domains at risk should all put in place immediately. It is possible to put what is known as a registry lock in place for your domain. This prevents even the registrar from making changes to the registry automatically.” While Prince notes that registry locks are often difficult to obtain from registars, this provides an extra layer of security. This was a key reason why Twitter.com was not affected, even though the company’s secondary domains were. Obviously, making that sort of change isn’t for everyone, but for associations that might face unwelcome attention from hackers, it could be a security step worth looking into.

How have you dealt with security issues that affected your association’s network or website in the past? Let us know in the comments.

The New York Times experienced downtime issues for more than a day after its domain records were hacked. (photo by Joe Shlabotnik/Flickr)