Dot-org zone offers lessons learned in implementing DNSSEC

Federal agencies are working with the Internet community to develop a process for securing the Internet’s Domain Name System by implementing the DNS Security Extensions (DNSSEC) in the authoritative root zone. The zone for the .org top level domain was signed with DNSSEC in June, and its operators have offered their insights to government planners.

In a July 17 letter to the National Telecommunications and Information Administration, Afilias Ltd. offered advice on protocols for minimizing computational overhead; processes for rolling over, distributing and securing cryptographic signing keys; and warned of a possible increase in bandwidth demand when DNSSEC is being used.

Afilias provides technical services to .org, the Internet’s largest signed zone, on behalf of the Public Interest Registry.

“Our recent DNSSEC deployment has garnered valuable insight into the trials and tribulations of running a large signed zone that receives billions of queries a day,” Afilias said in offering comments on NTIA’s proposed testing and implementation requirements for DNSSEC in the root zone.

The Domain Name System translates easy-to-understand names into IP addresses and underlies most activity on the Internet, but it was not designed to provide security. As a result, this basic service is vulnerable to spoofing and manipulation, which could allow hackers to redirect traffic to fraudulent sites.

DNSSEC was developed to address this problem by digitally signing DNS queries and responses so that they can be authenticated using public signature keys. The protocols have been in the works for about 15 years, but implementation has been slow because DNS has worked so well and nobody wants to fix what has not appeared to be broken.

DNSSEC complicates the systems administrators’ job by requiring key generation and management, signing records and securing private keys on an ongoing basis as signatures expire and new ones are needed.

“There is a lot more that has to go into security policy,” when DNSSEC is being used, said Howard Eland, Afilias’ senior director of content propagation and resolution.

And despite having been around for 15 years, DNSSEC has not been stable, he said. “There has been a lot of protocol churn,” and the current iteration was presented as a draft standard only a few years ago.

In late 2006, federal information security requirements called for agencies to use DNSSEC signatures on DNS servers classified as moderate- or high-impact information systems. But because most DNS servers are classified as low impact systems, there was little implementation in the .gov domain. Following disclosure last year of a serious vulnerability in the DNS protocols, however, the Office of Management and Budget mandated that the .gov top level domain be signed early this year, and that agencies sign their secondary domains by the end of the year.

The Public Interest Registry, which digitally signed its .org zone in June, has begun implementing DNS Security Extensions in a test environment for 18 live domains as part of its plan to launch DNSSEC services in the top level domain next year. The .org domain is the third largest of the open top level domains, behind .com and .net, with more than 7.5 million domains registered in it.

“We are the ones who are actually signing the zone on their behalf,” Eland said. “We are responsible for running the name servers at the top level” for .org and for 15 other top level domains.

One of the issues addressed by Afilias is the use of NextSECure (NSEC) parameters in DNSSEC for providing proof that a requested record does not exist. There are two schemes for this. NSEC proves nonexistence by responding with listings of the surrounding records. This technique can let users discover the entire contents of a zone by “walking” it with NSEC. NSEC3 avoids this by using hashes to affirm that a record does not exist. But this requires computational overhead.

“For .org, NSEC3 makes sense,” Eland said. It has the horsepower to deal with the hashing. But for a root zone, more than 90 percent of queries are for records that do not exist, he said. So root zones would require a lot of extra computing power for returning answers with NSEC3. Afilias recommends that the root zone use NSEC, because the zone’s records are public and “walking the zone” to discover content is not a threat.

Bandwidth is another issue to be considered. Although files returned on queries are small, the use of NSEC nearly doubles their size. In addition to this, .org saw a sharp spike it its TCP traffic. Afilias speculates this is because many versions of the popularly used BIND DNS server limit the size of UDP responses in DNS to 512 bytes. With the use of DNSSEC, responses contain more information than can be handled by UDP, so a new request is made using TCP, which can accommodate the larger response message. As a result, .org has seen TCP jump from .1 percent of its traffic to 10 percent of its traffic, a 100-fold increase.

The good news on this is that BIND 9.6.3 increased the UDP limit and eliminates the need to use TCP. Many organizations might upgrade to this version as a result of a recently announced vulnerability in other BIND 9 versions.

“As that gets proliferated around the ’net we may hope to see a decrease in TCP,” Eland said.