Forty years ago, when the U.S. government created the packet switching network that became the Internet, one of its goals was to create a robust network where traffic would be dynamically routed around blockages.
Now the Internet engineering community has developed a strategy to route around a different kind of blockage — one that is political, rather than technical — and one that has been caused by the U.S. government itself. At issue is the deployment of security mechanisms for the Internet’s Domain Name System, which matches domain names with corresponding IP addresses.
The Internet engineering community wants to deploy DNS Security Extensions (DNSSEC) to prevent hackers from hijacking Web traffic and redirecting it to bogus sites. DNSSEC uses digital signatures and public-key encryption to allow Web sites to verify their domain names and corresponding IP addresses. DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered last summer. It’s because of DNS threats like these that the U.S. government is rolling out DNSSEC across its .gov domain.
Despite its efforts to deploy DNSSEC on .gov, the U.S. government is delaying widespread DNSSEC deployment by failing to cryptographically sign the 13 “root” servers that operate at the pinnacle of the Internet’s hierarchical DNS. The root servers make it possible for top-level domains including .gov, .com and .net to resolve DNS requests for names registered in these domains.
Last fall, the U.S. government sought comments from industry about how best to deploy DNSSEC on the root zone, but it hasn’t taken action since then. Internet policy experts anticipate further delays because the Obama Administration hasn’t appointed a Secretary of Commerce to oversee Internet addressing issues.
Meanwhile, the Internet engineering community is forging ahead with an alternative approach to allow DNSSEC deployment without the DNS root zone being signed. Known as a Trust Anchor Repository, the alternative was announced by the Internet Corporation for Assigned Names and Numbers (ICANN) last week.
ICANN’s Interim Trust Anchor Repository — or ITAR — allows top-level domains such as .se for Sweden and .br for Brazil to have fully functioning DNSSEC deployments without waiting for the root zone to be signed.
ICANN officials were quick to say that their Trust Anchor Repository would be disabled as soon as the U.S. Department of Commerce requires root zone operators to deploy DNSSEC. “The ideal scenario is that the root zone is signed,” said Kim Davies, manager of root zone services for ICANN. “Currently, we have a situation where the root isn’t signed, which is largely a political discussion. And in the immediate future, it is not likely that we’ll have a signed zone. So we’re looking at what’s the next best thing.”
ICANN’s ITAR serves as a central clearinghouse for top-level domains to share their DNSSEC public keys. The ITAR publishes the public keys for each participating top-level domain in a single file on a regular basis so that domain operators can validate against the latest security information.
“This is a temporary service until the root is signed,” Davies said. “It’s kind of a stop-gap measure. Technologists would agree that it is not ideal, but it is the best we can do for now.” ICANN’s ITAR has been operating in test mode since October. Fifteen top-level domains are using ITAR, including some domains such as .gov and .museum that are experimenting with DNSSEC. ITAR is available free to top-level domain operators through ICANN’s Internet Assigned Numbers Authority.
ITAR proponents say it will encourage domain name operators to forge ahead with DNSSEC deployments without worrying that their efforts to authenticate DNS queries will be stymied because the root zone isn’t cryptographically signed.
“I don’t think ITAR is as scalable as having the root zone signed, and it’s not a replacement for having the root zone signed. But it does make early adopters have an easier time deploying DNSSEC,” Davies said.
The ITAR comes with some risk. Some argue that its existence could slow DNSSEC deployment. Others say that it could end up on the Internet forever, which would complicate DNSSEC deployment.
“We’ve seen no indications from the U.S. government or any other parties that [ITAR] will delay DNSSEC deployment,” Davies argues. “Signing the root is the only long-term proposition.”
He adds that ICANN has “been emphatic on the documentation of ITAR that it is a temporary service. Once the root zone is signed, we intend it to go away.”
Multiple Repositories Emerge
While ICANN’s ITAR is aimed at top-level domains that deploy DNSSEC, other Trust Anchor Repositories are being developed for lower levels of the DNS hierarchy.
Internet pioneer Steve Crocker, CEO of Shinkuro, says Trust Anchor Repositories are a “necessary piece of scaffolding to permit DNSSEC to work smoothly during the lengthy transition period until most of the [DNS] tree is signed.”
Even if the U.S. government mandates that the DNS root zone is cryptographically signed, the most popular top-level domains for online business–.com and .net — haven’t adopted DNSSEC. VeriSign, which operates both of these domains, won’t comment on its plans to deploy DNSSEC.
Until .com is signed, if an individual company with a .com address wants to deploy DNSSEC to protect its Web site from hijacking attacks, it needs a Trust Anchor Repository that operates at the .com level.
ISC is operating a trust anchor repository it calls DLV for DNSSEC Look-aside Validation to address this problem. DLV is a free service that any Web site operator who deploys DNSSEC can use to publish its public key and validate against other available public keys.
“ISC is running what I would call a real-time Trust Anchor Repository to distinguish it form the batch-oriented one that ICANN operates,” Crocker said. “DLV is open for business across everything, including .com and .net.”
Crocker said that ISC’s DLV is not picking up momentum as quickly as DNSSEC proponents had anticipated.
“The problem with ISC’s [repository] is that they have far fewer keys than exist in the world,” Crocker says. ”People are not registering in the numbers that one would have expected. And the other problem is that there is some concern about real-time look-ups and how well that will scale.”
Crocker said DNSSEC experts are working with ISC to address some of their concerns about the DLV repository.
Most Internet engineers say Trust Anchor Repositories are necessary to ease the transition to DNSSEC. But they warn that it’s important that repository operators are organizations such as ICANN that are trustworthy.
“If the owner of a zone is not signing it or creating a Trust Anchor Repository for it, then you have to go to somebody who you trust to publish your public keys and validate against other keys,” explains Paul Hoffman, director of the VPN Consortium and an active participant in the DNSSEC community. “There’s an important policy question about why should I trust this party to tell me about those other
