Security for Domain Name System Takes a Big Step Forward
Several Internet domain-name administration agencies participated in a ceremony 16 June to generate the first master key for securing the Internet's Domain Name System (DNS). The production-scale rollout of DNS Security Extensions (DNSSec) on the root zone is scheduled for 15 July. "This will eliminate the last significant hurdle toward the widespread adoption of DNSSec," said Matt Larson, vice president of DNS Research at VeriSign.
DNSSec on the root zone will provide a common anchor of trust for securing the way domain names are translated into IP addresses. Participants in the signing ceremony included the Internet Corporation for Assigned Names and Numbers (ICANN), the US National Telecommunications and Information Administration, and VeriSign, which manages two of the world's 13 root-name servers.
DNSSec is an Internet Engineering Task Force (IETF) specification that provides a way of cryptographically signing DNS queries to prevent cache-poisoning attacks that can trick computer users into going to fake websites. Steven Bellovin first documented this attack vulnerability in 1990, but it proved difficult to carry out in practice. Work on DNSSec work began seriously in 1999 with the release of IETF RFC 2535, but progress was slow until 2008, when Dan Kaminsky published an easier method of launching cache-poisoning attacks. Since then, there have been many cases of fraud perpetrated by misdirecting users to bogus sites without their knowledge, said Larson.
Under the Cover
DNSSec is based on a recursive key-management system built using public-key cryptography. A master key authenticates top-level domain (TLD) keys, which in turn authenticate individual domain name keys. This helps simplify the problems associated between establishing a secure chain of trust between two individuals, since they can both share the same public key generated by the root-zone server.
Without such a system, attackers in the middle might listen to and copy an organization's key or substitute their own keys. By having the root signed, it becomes a lot easier to administer the servers that will validate a site using a key that is recursively signed by the root server.
The isolated networks of DNSSec have traditionally required DNS server administrators to configure the root certificates for each domain separately, which can be a challenge said Mark Beckett vice-president of Marketing and Product Management at Secure64, a DNSSec software vendor. With the signing of the root zone, a DNS administrator will only have to enter keys for the root zone, which will be able to globally authenticate the other zones. "It greatly eases the administrative burden for a lot of network operators," said Beckett.
The DNSSec is rolling out on multiple parallel tracks. The registrars of TLDs, such as .net and .com, are moving to support the capability and provide keys that individual domain owners can use. DNS server administrators must also turn on the capabilities, which domain name owners must subsequently turn on and configure their name servers for. Finally, end-user software must be configured to support DNSSec management and policies on the use of this information.
Several country TLD registrars have already adopted DNSSec for their subdomains including Brazil, Bulgaria, the Czech Republic, and Sweden. The US Government also enabled DNSSec and mandated its use for all .gov and .mil sites in 2009. VeriSign launched DNSSec for the .org TLD in June and plans to add support for .edu in July. The company will support .net by the end of 2010 and .com in early 2011, said Larson.
The biggest issue lies in getting organizations that own domain names to participate, said Ed Stoner, network analyst with the CERT Program at the Carnegie Mellon University Software Engineering Institute. For DNSSec to be effective, most if not all organizations need to sign their zones. Key management systems must be in place both at the organizational level and at the registries and registrars. "Many registries and registrars have already done a lot of hard work to support this transition," said Stoner, "but there is still more work to do."
Another hurdle lies in deploying and using this information in client applications. There has been some progress in this area. Both Windows 7 and the Drill extension for Firefox now support DNSSec on the client. But the end user must decide what to do with this information if the DNSSec certificate information is faulty or the site hasn’t been upgraded.
Upgrades are also needed on firewalls, spam filters, and other Internet appliances that currently block the larger UDP packets used for carrying DNSSec data. Current DNS packets tend to max out at about 512 bytes, while typical DNSSec packets are expected to average around 1500 bytes, and some will be even larger, said Beckett.
July 15 will mark the launch of a long, gradual rollout, said Beckett. "It will encourage a more rapid adoption, but there will not be a big bang. It will take time before we see DNSSec doing what it was designed to do, which is protect consumers from having domains hijacked on them."
DNSSec might open the door for the DNS to securely authenticate information such as identity. "We will see more and more applications put information into DNS," Larson said, "because it will provide a secure way to send information without it being modified. We will see a flowering of uses of DNS as people put more information into it."
George Lawton is a freelance journalist based in Guerneville, CA. He can be reached via his website at http://glawton.com.