How NIST put DNSsec into play

The digital signing of the .gov top-level domain in February completed the first step of the implementation of DNS Security Extensions (DNSSEC) in the government’s Internet space. The next step is for agencies to sign their second-level domains by the end of the year.

It is not a simple process, which is one of the main reasons DNSSEC has not been widely deployed across the Internet’s Domain Name System despite its well-known vulnerabilities.

“There is a steep learning curve in deploying DNSSEC,” said Scott Rose, a computer scientist at the National Institute of Standards and Technology, the agency that is writing the rules for deployment. DNS typically takes little management. However, once DNSSEC is deployed, there is the constant chore of generating and managing cryptographic keys and signing and re-signing data.

But NIST is doing more than writing about it. The agency has had DNSSEC deployed in the NIST.gov domain for more than a year.

“We’re ready now,” Rose said. “We’re just ironing out and hardening processes,” refining best practices and changing security parameters so that acceptable levels of security can be maintained under the weight of DNSSEC management.

That is not to say that the process was — or is — easy, or that the full benefits of DNSSEC will be realized soon.

Robert Toense, an electronics engineer in NIST’s Office of the Chief Information Officer, said it still takes about 30 minutes a day to sign the updated zones, and “there is no well-defined method for exchanging keys” so that chains of trust can be established. And you don’t get the full benefits having digitally signed DNS data without chains of trust. “That’s some of the work that's going on now.”

Still, if agencies examine how DNS is being used in their network architecture and set their sights on reaching minimum requirements, they can meet the Office of Management and Budget’s Dec. 31 deadline for DNSSEC deployment.

The 26-year-old DNS maps domain names to IP addresses and underlies nearly all Internet activities. DNS replaced the Host Table naming system, which dates back to the Internet’s predecessor, ARPAnet, and predates the implementation of TCP/IP. A centrally managed file maintained by the Network Information Center at Stanford University was updated every week or so to map host names to locations.

That approach was adequate in the pioneering days of the interconnected network, but it would not scale to the levels needed as the Internet grew. DNS is a distributed, hierarchical scheme that lets everyone look up addresses without having to maintain a separate copy.

DNS has been successful at scaling to serve the Internet community, but like the rest of the infrastructure, it was not built with security in mind. Experts have been aware of the possibility of hackers poisoning DNS caches to misdirect or hijack traffic for some time, but last July, a significant flaw in the protocols was announced that made securing the system more urgent.

DNSSEC enables DNS queries and responses to be digitally signed using cryptographic keys so they can be authenticated and are harder to spoof or manipulate. In late 2006, new federal information security requirements called for agencies to use DNSSEC signatures on DNS servers that are classified as moderate- or high-impact information systems. Little implementation was done, however, in part because most servers were classified as low-impact and in part because managing DNS can be complicated. It involves cryptographic keys and digital signatures that must be refreshed regularly if they are to remain secure.

In the wake of last July’s vulnerability announcement, OMB issued a memo requiring deployment of DNSSEC at the top-level .gov domain by January 2009. The General Services Administration, the lead agency in the program, missed the deadline by about a month but announced that DNSSEC became operational in the .gov domain on Feb. 28.

Agencies now have until the end of the year to sign their zones, although NIST had signed its zones well before OMB issued its mandate.

“We’re NIST, we should be doing things on the leading edge,” Toense said. “But there was always the pain of doing it. Then the government came along with an incentive” with the original 2007 deadline.

Because NIST was responsible for establishing the guidelines for deploying DNSSEC, it seemed as though the agency should have some practical experience, Toense said. “We were feeling that most of the government wasn’t going to make it, but NIST was going to do its damnedest.”

One of the first steps was to examine the NIST network to find out how many zones it had.

“We had partitioned things so that we would have to do a lot of signing,” Toense said. Fortunately, the agency no longer needed to maintain most of those partitions. “I spent a lot of time collapsing zones,” reducing the number from about 200 to about 15 zones for which keys would have to be managed.

But that was not the only challenge. The NIST zones have about 10,000 records that must be updated regularly, which is not a very big database. “In non-DNSSEC terms, that was not difficult to manage.” But when it came time to sign them on a powerful server that could handle routine DNS work at idling speed, the signing process took 100 percent of the server’s CPU cycles for 15 minutes. And the process had to be performed twice for every update because domain-to-IP address lookups are handled separately from IP address-to-domain lookups. That means every time the records are updated, it requires 30 minutes of DNSSEC signing, and a batch update is done nearly every day.

That burden could be eased by dynamic DNSSEC, which would allow updates to be signed on the fly rather than re-signing the zone during batch updates, but at this point there is no standard support for dynamic DNSSEC. And the entire zone will have to be re-signed eventually anyway. Another solution could be dedicated DNSSEC appliances, which have begun to appear and could automate much of the process.

“We’re working with some of them,” Toense said. “None of them have a complete solution yet that I’m aware of. But they are all trying very hard, realizing it is not a simple problem.”

The appliances are being tested on a laboratory network called the Secure Naming Infrastructure Pilot (SNIP), which is designed to give administrators some real-world experience managing a signed DNS zone on a live network.

“We have set up a test bed at dnsops.gov,” Rose said. “The main purpose is to give government agencies an environment they can test in.” A test bed for vendors to try products has been set up at dnsops.biz.

Among the appliances being tested on SNIP is Secure64 Software’s DNS Signer, which automates key generation, key rollover, zone signing and re-signing. It was developed with a Homeland Security Department grant and is built on the company’s SourceT secure micro-operating system.

“You have to think about the security of the signing keys,” said Mark Beckett, vice president of marketing at Secure64. DNS Signer keeps the keys online in secure boxes within SourceT so that the signing processes can be automated.

Afilias Ltd., the registry for the .info and .aero top-level domains, is taking another approach. The company plans to launch its 1-Click DNSSEC later this year as an add-on to its Managed DNS service. It would automate creation and management of keys and signing and the distribution of public keys to parent zones — all as a managed service rather than an appliance.

Right now, the lack of standards for exchanging keys with parent zones is a stumbling block to establishing the chains of trust that can make DNSSEC really effective, Toense said.

In the meantime, “you can be a trust island,” he said, without exchanging keys with other zones. That is all that the mandate currently requires, and that is what NIST has done. “Local key management was all we needed to do.”

But that will change soon, he predicted. The need for improved security will spur the adoption of standards and best practices once zones are being signed.