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.

Vulnerabilities / Threats

4/5/2011
02:35 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

DNSSEC Finally Comes To .com, But Secure DNS Still Has A Long Way To Go

Half of IT security experts either don't know what DNSSEC is or don't understand it very well

The DNSSEC protocol for securing the Internet Domain Services Name (DNS) is now fully deployed at the root servers and top-level domains, with the last of the domains and the biggest -- .com -- signed with DNSSEC late last week. But the milestone is still lost on many organizations that remain unaware or unsure about the DNS security technology.

Like any newly available technology, DNSSEC is more of interest to large organizations that have the highest stakes in securing their domains -- as well as the most resources and know-how to deploy and manage it. A new survey released on March 30 -- the day of the .com-signing led by VeriSign, which operates the .com domain -- found that half of corporate IT security experts had either not heard of DNSSEC at all or didn't really understand it well. About 5 percent of the respondents in the study -- conducted by Internet Identity (IID) and the Online Trust Alliance -- say they have already rolled out DNSSEC for their domains, and another 16 percent say they plan to do so.

This lack of awareness and knowledge of DNSSEC doesn't worry Dan Kaminsky, the security researcher who discovered the deadly DNS cache-poisoning attack that ultimately gave DNSSEC a much needed kick-start after more than 15 years in the making and limited adoption. "Most organizations deploy their networks under the .com TLD, which just got signed. It's going to take time for administrators to even become aware of this new security capability, let alone determine what it would take to integrate it into their networks. It will also take time for products to be developed that depend on DNSSEC being deployed," Kaminsky says.

Kaminsky, who wasn't initially a fan of DNSSEC and changed his mind upon further inspection, says DNSSEC adoption in the Internet is inevitable. "But it will happen because, for a long time, the Internet has been suffering severe problems with authentication -- problems X.509-based PKI just cannot fix, but DNSSEC can," he says.

"That we're on the path to fix these issues is the revolution."

A Forrester Research survey last summer commissioned by VeriSign found a similar lack of knowledge of DNSSEC, with some 57 percent of IT decision-makers saying they had never heard of the technology. Some 11 percent of organizations surveyed were running DNSSEC, and most of those familiar with the technology had either deployed it or planned to do so.

But that study (PDF) was more from the perspective of heavy hitters, such as financial services firms and ISPs, for instance, which are expected to be the early adopters of DNSSEC, notes Mark Beckett, vice president of marketing at DNS security company Secure64.

"We're already seeing larger, more security conscious organizations paying attention," Beckett says. "In my experience, the larger, more brand-conscious organizations [are looking at DNSSEC]."

Even so, you won't see .coms going DNSSEC right away, he says. "There's still a lack of understanding in the general market about what DNSSEC is and what problem it's solving. If you're going to get smaller organizations living under .com to care, there's still a lot of education [to go]," he says.

The signing of the .com top-level domain, indeed, was a big milestone: .com represents just less than half of the total number of Internet domains. "The signing of .com means that more than half of the world's domains can now potentially benefit from DNSSEC," Secure64's Beckett says. "That throws DNSSEC over a significant hurdle."

DNSSEC is a protocol for preventing attackers from redirecting users to malicious websites by redirecting them -- it basically ensures DNS entries remain unchanged in transit and are digitally signed to ensure their authenticity. The protocol finally began to take off last July when the Internet root servers all went DNSSEC, and since then, .gov, .org, .edu, .net, and other domains have added DNSSEC. The .com top-level domain is the largest TLD, with more than 80 million registered names, according to VeriSign.

Matt Larson, vice president of DNS research at VeriSign, says there are several more steps to go for widespread DNSSEC deployment. "First, Internet service providers, website operators, and registrars needs to implement DNSSEC across the domains they manage. Next, ISPs and enterprises need to enable DNSSEC validation in the recursive name servers that their customers' computers and devices use to look up DNS information," Larson says. "Ultimately, Web browsers and other applications will need to be modified to take advantage of this now secure and trusted DNS infrastructure."

Once ISPs, website operators, and registrars deploy DNSSEC across the domains they manage, he says, Web browsers and applications will need to be updated to use DNSSEC, as well.

But even those organizations fully versed in DNSSEC find that it's not exactly a plug-and-play process to convert DNS servers to DNSSEC. Secure64's Beckett says it's easy to make a mistake, like forgetting to re-sign a zone when the DNSSEC certificate expires. "A mistake [like] that could take your domain off the Net," he says. "If your signatures are no longer valid because you forgot to re-sign them, someone trying to reach your domain who has turned DNSSEC validation on will think your domain is bogus, or someone cache-poisoned it," he says.

Another gotcha could be your network. Beckett says the corporate network must be able to handle the packets DNSSEC generates. That takes a bit of planning and fine-tuning of the network.

Key management is another challenge for DNSSEC adopters. Aside from keeping the signatures up to date, administrators should look out for invalid keys. "Likewise, securely storing the keys is critical to ensuring they don't become compromised," VeriSign's Larson 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.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-23872
PUBLISHED: 2021-05-12
Privilege Escalation vulnerability in the File Lock component of McAfee Total Protection (MTP) prior to 16.0.32 allows a local user to gain elevated privileges by manipulating a symbolic link in the IOTL interface.
CVE-2021-23891
PUBLISHED: 2021-05-12
Privilege Escalation vulnerability in McAfee Total Protection (MTP) prior to 16.0.32 allows a local user to gain elevated privileges by impersonating a client token which could lead to the bypassing of MTP self-defense.
CVE-2021-23892
PUBLISHED: 2021-05-12
By exploiting a time of check to time of use (TOCTOU) race condition during the Endpoint Security for Linux Threat Prevention and Firewall (ENSL TP/FW) installation process, a local user can perform a privilege escalation attack to obtain administrator privileges for the purpose of executing arbitra...
CVE-2020-36289
PUBLISHED: 2021-05-12
Affected versions of Atlassian Jira Server and Data Center allow an unauthenticated user to enumerate users via an Information Disclosure vulnerability in the QueryComponentRendererValue!Default.jspa endpoint. The affected versions are before version 8.5.13, from version 8.6.0 before 8.13.5, and fro...
CVE-2021-32606
PUBLISHED: 2021-05-11
In the Linux kernel 5.11 through 5.12.2, isotp_setsockopt in net/can/isotp.c allows privilege escalation to root by leveraging a use-after-free. (This does not affect earlier versions that lack CAN ISOTP SF_BROADCAST support.)