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.

Perimeter

2/24/2010
04:58 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Comcast Goes DNSSEC, OpenDNS Adopts Alternative DNS Security

DNS provider OpenDNS selects DNSCurve over DNSSEC, but experts say the two technologies could eventually play together

Domain Name System (DNS) security was hot this week, with the much-anticipated DNSSEC technology for locking down domain servers getting both the nod from a major ISP and passed over by a DNS service provider.

Comcast has announced it will deploy DNSSEC in its Websites, including comcast.com, comcast.net, and xfinity.com, by the first quarter of next year, and it will begin using DNSSEC validation for all of its customers by the end of 2011. In a separate announcement, meanwhile, OpenDNS said it had deployed an alternative to DNSSEC, DNSCurve.

OpenDNS engineer and security researcher Matthew Dempsky says the company "put a lot of thought into" adopting DNSCurve at this time and concluded it made more sense than DNSSEC because it's simpler and easier to deploy and manage than DNSSEC -- and because it uses stronger cryptography. "DNSSEC is not a very viable solution as a whole," Dempsky says. "While there are increasing efforts to deploy it ... there's been a lot of testing with questionable results. There are still a lot of compatibility issues to be worked out."

DNSSEC adoption has finally begun gaining traction during the past year after nearly 15 years in the making. Concerns about how to defend against the DNS cache-poisoning flaw discovered by Dan Kaminsky have helped invigorate DNSSEC adoption efforts by government and industry. The .gov and .org top-level domains have begun to adopt the DNS security protocol, and .edu has been under way recently, as well.

The root zone DNS servers will be "signed" with DNSSEC technology in July, and VeriSign plans to deploy DNSSEC in the .com, .net, and .edu domains by the first quarter of 2011. "The critical mass has started," says Matt Larson, vice president of DNS research for VeriSign, which today rolled out its anticipated DNSSEC Interoperability Lab for vendors and service providers. "You're starting to see the snowball begin to roll down the hill with DNSSEC this year."

But OpenDNS' Dempsky argues that DNSSEC adoption is not far along and that DNSCurve is the technology for "right now" for preventing the Kaminsky DNS cache-poisoning attack and other threats. He says DNSSEC's RSA 512-bit and 1024-bit keys aren't secure enough given recent crypto hacks, and aren't up to date with recommended 2028-bit keys.

In addition, DNSSEC's use of digital signatures to authenticate Website domain information is inefficient, according to Dempsky. DNSCurve uses a different approach: per-packet encryption and authentication. The two technologies aren't interchangeable, per se -- DNSCurve is aimed more at transactional security between pairs of name servers, while DNSSEC protects the zone data, says Cricket Liu, vice president of architecture for Infoblox and author of several DNS books. "They don't address the same spectrum of threats," Liu says.

And unlike DNSSEC, DNSCurve isn't an IETF-backed technology, although OpenDNS's Dempsky has written a draft of the protocol for the IETF that he hopes will be accepted by the standards organization.

Infoblox's Liu called OpenDNS's choice to go with DNSCurve "regrettable" given all of the community effort to finalize and push DNSSEC forward. "This is potentially diluting the focus on DNSSEC," he says.

Even so, Liu and VeriSign's Larson say the two technologies could ultimately be used together. "DNSCurve is clever and solves some problems," Liu says. He says DNSCurve is basically a bootstrap for the existing transactional security standard used in DNS today. "So in the communication between two name servers, it's able to check that what you hear is what I said," he says. But unlike DNSSEC, it can't determine "if I'm lying to you," for example.

"Over time, it might be possible for these [technologies] to be used together," Liu says. "But they are not two different options for solving the same set of problems."

One area where there might be symmetry is in cryptography. VeriSign's Larson says DNSSEC is architected such that it can swap crypto algorithms, so although the focus for now is on the widely implemented RSA algorithms, DNSSEC could potentially deploy the Elliptic Curve Cryptography (ECC) used by DNSCurve. "VeriSign is very interested in that," he says. "I absolutely see adding ECC to it in the next couple of years."

For now, OpenDNS runs the only known operational implementation of DNSCurve, according to Dempsky. But the company has had several inquiries to its invitation for others to join as well. Dempsky says OpenDNS has not yet decided on any plans for DNSSEC adoption.

Have a comment on this story? Please click "Discuss" 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
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/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-27905
PUBLISHED: 2021-04-13
The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To...
CVE-2021-29262
PUBLISHED: 2021-04-13
When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be rea...
CVE-2021-29425
PUBLISHED: 2021-04-13
In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "...
CVE-2021-29943
PUBLISHED: 2021-04-13
When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.
CVE-2021-28938
PUBLISHED: 2021-04-13
Siren Federate before 6.8.14-10.3.9, 6.9.x through 7.6.x before 7.6.2-20.2, 7.7.x through 7.9.x before 7.9.3-21.6, 7.10.x before 7.10.2-22.2, and 7.11.x before 7.11.2-23.0 can leak user information across thread contexts. This occurs in opportunistic circumstances when there is concurrent query exec...