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

02:35 PM
Connect Directly

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
Newest First  |  Oldest First  |  Threaded View
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
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
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.