Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Domain Security Needs More Than Registry Locks

Protecting domains requires registry locks as well as other measures, including two-factor authentication and administrative access control

Today's networking infrastructure relies on the domain name system -- not only a company's public-facing Web servers and Internet appliances, but much of its private infrastructure as well.

But enterprises need to better protect their DNS environments, as last week's attack on a reseller of domain registrar MelbourneIT and the subsequent redirection of The New York Times, the Huffington Post, and two subsidiary Twitter domains demonstrated. While the attacks should not have come as a surprise, the vast majority of companies are unprepared for such malicious attention.

Only a small fraction of companies are taking the security measures necessary to protect their domains from attack, says Danny McPherson, vice president and chief security officer for VeriSign. Even companies and individuals that are conscious of security issues tend to give their domain name registrations short shrift, he says.

"People invest tens or even hundreds of millions of dollars on content distribution infrastructure, data centers, and other things, and they use a fixed password with their registrar and a $10 domain name," he says.

Following last week's compromise, companies jumped to protect their domains from changes using a registry security feature known as a registry lock. Yet McPherson and others point out that a registry lock, while an essential step to protecting a business's domain, is not sufficient. Companies need to take an in-depth look at how they handle their domains, who has access to those domains, and the vetting of their registrars, he says.

Two documents produced by the Internet Corporation for Assigned Names and Numbers (ICANN) are a good starting point for companies. Produced by ICANN's Security and Stability Advisory Committee, the documents -- SAC040 and SAC044 -- inform companies about the measures their registrar uses to protect registration services against misuse and advises businesses about how to protect their own domain names.

As described, a registry lock protects domains against changes, deletion, and transfers using registrar status codes. But security experts and the documents recommend other steps as well:

1. Check out your registrar
By all accounts, MelbourneIT is a responsible, security-conscious registrar. Despite that good reputation, hacktivists circumvented the company's business processes to gain control of its domain administration system for a short time.

Like any third party, registrars should be quizzed on their security measures, says Jaime Blasco, director of research for unified-security provider AlienVault. While smaller firms may not have the clout of larger firms, they can still shop around and ask for additional security measures for their domain, he says.

"If you are a big company, ask the registrar what security mechanisms do they have in place as part of your risk-assessment process," Blasco says. "Taking into account how secure the registrar is should be one of the priorities for companies right now."

2. Passwords are not good enough
Securing the foundation of business infrastructure with a simple password, no matter how complex, is dangerous. Any business that does not take more stringent security measures is a single phishing attack away from losing their domains, says Rodney Joffe, senior vice president and technologist at domain-registry Neustar.

Companies should have at least two-factor authentication in place, so that any change to the domain records requires a passcode sent or generated through another channel. Because e-mail accounts tend to be a first target of attackers, using two-factor authentication that relies on e-mail is not good enough, Joffe says.

"Obviously if a domain holder's email account has been compromised, the hijacker can still get the second factor and make changes, so the better systems typically utilize text messages to cell phone numbers," he says.

3. Track access to DNS records
While two-factor authentication can shrink the attack surface area that leads to a company's domain records, businesses also need to minimize the number of employees with the ability to change a domain records. At the same time, having multiple points of contact can add redundancy that is important in an emergency.

Overall, companies should make sure that each step of the domain name system has adequate points of contact and verify that only the people who need to access the systems have authorization, says VeriSign's McPherson.

"It's important for people to consider the ecosystem, all the way from the registrant, all the way forward to something like DNSSEC to even validating recursive name servers in the infrastructure," he says. "It helps you to minimize your attack surface in the active infrastructure."

[A report has sparked a new round of discussions about policing the Internet ecosystem and whether the Internet Corporation for Assigned Names and Numbers (ICANN) is doing enough to combat the problem. See Rogue Domain Registrars Pose Challenges.]

4. Monitor your DNS records for changes
Registry locks, DNS Security and other technologies are not infallible protections against attackers, but are methods of raising the bar higher. But just as important, in circumventing the protections, attackers will essentially set off alarms.

For that reasons, companies need to be monitoring their DNS records to any unauthorized changes, says AlienVault's Blasco.

"Implementing monitoring and health checks of the infrastructure is one of the key things that companies can do," he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline ... View Full Bio


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-07
MobileIron Core and Connector before, 10.4.x before, 10.5.x before, 10.5.2.x before, and 10.6.x before, and Sentry before 9.7.3 and 9.8.x before 9.8.1, allow remote attackers to execute arbitrary code via unspecified vectors.
PUBLISHED: 2020-07-07
MobileIron Core and Connector before, 10.4.x before, 10.5.x before, 10.5.2.x before, and 10.6.x before allow remote attackers to bypass authentication mechanisms via unspecified vectors.
PUBLISHED: 2020-07-07
MobileIron Core and Connector before, 10.4.x before, 10.5.x before, 10.5.2.x before, and 10.6.x before allow remote attackers to read files on the system via unspecified vectors.
PUBLISHED: 2020-07-07
In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. Apps using "contextIsolation" are affecte...
PUBLISHED: 2020-07-07
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. As a workaround, ensure you are calling `event.preventDefault()` on all new-window events where the `url` or `options` is not ...