Can .gov trust .com?

The last of 13 servers in the Domain Name System’s authoritative root zone was digitally signed with the DNS Security Extensions May 5, paving the way for the publication this summer of the root trust anchor that will remove a major hurdle to the widespread deployment of DNSSEC.

“Since the beginning of the year, we have been incrementally rolling out DNSSEC in the root zone,” said Joe Waldron, director of product management at VeriSign Naming Services.

The DNS root zone, which contains the records needed to resolve the domain names used by people and applications to the numerical IP addresses used by routers and servers, is overseen by the Commerce Department’s National Telecommunications and Information Administration, and the files are managed by VeriSign. DNSSEC provides a layer of security on the Internet by using cryptographic digital signatures to authenticate responses to DNS queries. The effort by NTIA, VeriSign and the Internet Corporation for Assigned Names and Numbers to deploy DNSSEC in the root zone has been called the biggest structural improvement to the DNS in 20 years.

Related stories:

DNSSEC's early adopters provide test beds for others
How DNSSEC provides a baseline of Internet security
The .org domain set to sign off on the largest DNSSEC implementation to date
Government implements DNSSEC on the .gov domain
How NIST put DNSSEC into play

The first of 13 authoritative root servers, the L Root run by ICANN – the servers are identified by the letters A through M – was signed in January. The J Root, run by VeriSign, was signed in May. You probably didn’t notice these milestones because during the transition, the NTIA has been creating a Deliberately Unvalidatable Root Zone (DURZ), which delivers signed responses not yet capable of being validated.

“One of the principles of DNS is that all root servers deliver the same information,” Waldron said. So a query response from any of the servers should be identical to a response from any other server. “You don’t want an inconsistent response,” with one server delivering a validated DNSSEC response and another server not.

“We are effectively testing the impact of a signed root zone on the system with all 13 root servers now serving the DURZ,” said NTIA press secretary Jessica Schafer. “Thus far, no harmful effects have been identified.”

If this state of affairs continues, “in the coming months, we expect to authorize ICANN to publish the root zone trust anchor and VeriSign to distribute a validatable signed root zone,” Schafer said. That event, now scheduled for July 1, will be a major milestone for DNSSEC. “Top-level domains (TLDs) will be able to take better advantage of DNSSEC by publishing their keys in the signed root zone. The combination of a signed root and signed TLDs will make it easier for operators to enable DNSSEC.”

The trust anchor is essential to making DNSSEC practical because the whole point is to use digital signatures from signed domains to ensure that DNS responses can be trusted. An individual signature is validated by following a chain of signatures to a key that provides the top level, or anchor, of trust. For a complete chain of trust, each domain and subdomain must be signed and validated, which is not yet the case.

Top Down

Some TLDs already have been signed. The .org TLD was signed in 2009 and has been testing DNSSEC with a select group of test domains. It is the largest generic TLD to be signed so far, with 7.5 million registered domains, and is scheduled to begin accepting general second-tier signed zones this year. The .gov TLD was signed in 2009 under a mandate, and .us, one of more than 200 top-level country codes, was signed in December 2009. But those domains are operating as islands of trust, and verifying digital signatures across domains is cumbersome.

“The stumbling block now is that there is not an effective solution in key management between signed zones,” said Branko Miskov, director of product management at BlueCat Networks, which sells DNS management tools. “There are a number of schemes for exchanging keys, but no real solution. The endpoint is all of the root zone will be signed.”

The imminent publication of the trust anchor is spurring more deployment of DNSSEC. The two largest TLDs, .net and .com, are expected to be signed in the fourth quarter of this year and the first quarter of next year, respectively. The .edu TLD has already been signed and has been acting as a test bed for DNSSEC deployment, but keys have not yet been published. Plans originally called for .edu to go live before now. But when plans were announced to finalize the root zone in July, publication of .edu keys was delayed until the summer, said Rodney Petersen, director of cybersecurity initiatives at Educause, registrar for .edu.

Signing the root zone has caused a quickening of DNSSEC deployment, said Steve Crocker, chief executive officer of Shinkuro, a research and development company hired by the Homeland Security Department to foster use of the technology.

“We are in the early days of deployment,” Crocker said. “We have some early adoption, and things are well on their way but still far away from the end point.”

The U.S. government has been the driving force and one of the early adopters of the development of commercial products for implementing and managing DNSSEC. But even the government has been lagging in deployment. The Office of Management and Budget mandated that the General Services Administration sign the .gov TLD by January 2009 and that agencies sign their subdomains one year later. GSA came pretty close, missing its deadline by only a month. But most agencies missed the January 2010 deadline, and five months later, only about a quarter of government domains have been signed.

“It’s hard to measure,” said Scott Rose, a computer scientist who is the DNSSEC lead at the National Institute of Standards and Technology. GSA, which manages the .gov TLD, considers the information sensitive, and detailed statistics are not available. But a compilation of domains by NIST showed that as of mid-May, only 259 out of 985 .gov domains had been signed. But the list also includes nonfederal domains within the .gov TLD, such as state and local governments that are not required to use DNSSEC.

Waiting for Results

So far, there has been little practical result from the government deployments because validation of the signatures has not yet been required. The DNSSEC deployment demonstrates the limits of government mandates, Rose said.

“There is a difference between making somebody do something and having them want to do it,” he said. “If you want to do it, you want to do it right. If you have to do it, you just want to get it done.”

But Miskov said interest is picking up among BlueCat’s federal customers, who have been enjoying what he said is an undocumented grace period.

“Most customers have already missed the deadline,” he said. “But we’re seeing more traction now than we were last year.” Those who last year did the bare minimum to prepare for DNSSEC are now “deploying in earnest. We have a healthy pipeline of customers.”

A primary reason for the slow deployment of DNSSEC is that, until now, DNS has been simple to run and did not require a lot of management. The addition of digital signatures and task of managing cryptographic keys place an administrative burden on network operators. However, the burden has lessened somewhat during the past two years as tools have appeared to automate the task of signing records and managing the expiration and rollover of signing keys.

“Within your own zone, it has become easy to manage,” Miskov said. “You can set up a zone in a matter of minutes with a few clicks.”

Tools for managing DNSSEC among zones are not as developed but are maturing, and they now run the gamut from hardware appliances and software to managed hosted services. But besides managing DNSSEC, there is the challenge of determining how other networking equipment handle the protocols. DNS packets for validated signatures are larger than those that do not use DNSSEC, and many devices are not used to dealing with them. The larger packets violate many firewall policies, so many DNSSEC packets will be blocked.

To help address those practical issues, NIST, Sparta and DHS have established the Secure Naming Infrastructure Pilot as a test domain. Operators can obtain a delegation within the SNIP domain at DNSops.gov to mirror their operational procedures, sign the new zone with DNSSEC and explore what else they need to do to maintain a digitally signed zone.

VeriSign also has established an interoperability lab to test networking equipment with DNSSEC. VeriSign provides the lab's staff and intends the lab to provide information about the performance of firewalls, load balancers and other equipment that will need to deal with the larger packets. It does not provide any certification, Waldron said.

Several large networking vendors, such as Cisco Systems and Juniper Networks are using the lab. “For the most part, we’ve had very good results,” Waldron said.

The focus on DNSSEC so far has been in core network infrastructures, and the technology has only lately begun moving to desktop applications. There are browser plug-ins for Firefox and some other browsers, and DNSSEC validation is built in to Microsoft’s new Windows 7 operating system.

“That is a double-edged sword,” NIST’s Rose said. A policy is set in the operating system about what domains you expect DNSSEC validation from. But if something under that domain has not been signed, the request comes back as unreachable. “It won’t tell you that DNSSEC failed. It’s a little too aggressive right now because it expects validation” that will not necessarily be available throughout a domain. Rose suggested that a better model would be to return a message that validation was not available and ask the user whether he or she wants to continue to the site.

Although more TLDs and subdomains are being signed, they only form islands of trust on the Internet. Until there is a complete chain of digital signatures that can be validated from a specific site to a root zone, bridging those islands will be a challenge. After all .gov is signed and using DNSSEC, for example, users within that TLD will be assured of the authentication of responses but not necessarily assured of responses coming from .com.

“The limiting factor is that not everyone is playing now,” Miskov said. “Until DNSSEC becomes ubiquitous and everyone is using it, it will take a lot of management to connect the islands of trust.”

Still, until all links are secured with DNS, Waldron said, “any secured link is an improvement.”