Published: 17 Jul 2008
What You Need: DNSSEC
|DNS turns 25 this year. It's high time DNSSEC is added to the protocol.
Like most of the early Internet protocols, DNS wasn't meant to carry the burden it does today. It wasn't built with an Internet-as-ecommerce platform in mind. It wasn't built to contend with cache poisoning, denial-of-service attacks, phishers, pharmers, spammers or any type of scammer.
DNS turns 25 this year, and it's showing its age. Coauthor Paul Mockapetris says DNS was built as a "modest" replacement for host tables that were used to keep track of network machines. The end result was the DNS we've come to know and love: a protocol that translates domain names into IP addresses. That's what was needed back on Jan. 1, 1983 when computers on the ARPANET were required to switch to the TCP/IP protocol.
What's needed today is DNSSEC, more formally known as DNS Security Extensions. These help defend against some of the aforementioned attacks against DNS servers, either enterprise servers or the root DNS servers that run the Internet and have twice successfully been attacked. DNSSEC provides origin authentication of DNS data, data integrity and authenticated denial of existence, according to the project's website. Numerous problems have inhibited widespread deployment, namely issues with scalability and compatibility with different DNS servers.
But Mockapetris and other DNS pioneers such as BIND8 technical architect Paul Vixie and DNS handbook author Cricket Liu believe the IETF is close to ratifying it. Close to a half-dozen times DNSSEC has been on the doorstep, only to be sent back to the drawing board because real world problems shattered what's been successful in a lab setting.
"Things are looking up," says Vixie, president of the Internet Software Consortium. "Participation we got for the latest go-round from the top-level domain holders has been good. We have been able to add the parts they said were missing without invalidating any previous work. There really is hope; again, I'm cautiously optimistic that we're going to see large islands of security in the DNS within next year."
DNS was built based on trust between the system and user. A quarter-century ago, it worked great in friendly research networks. But, through no fault of their own, Mockapetris and other early contributors didn't foresee a day when data could be subverted and money made on stolen data packets. Today, even vigilant users could fall victim to a cache poisoning attack that reroutes legitimate traffic to a phishing site. DNSSEC would add digital signatures to DNS data, enabling an organization to verify that data has not been altered since it was signed and that it came from the intended sender.
"It's high time to roll out DNSSEC and high time to implement it," Liu says. "One of the really big challenges is that people have a hard time with administering just plain, vanilla zone data. Once you start to factor in key generation, re-signing zones every time you modify them, and creating and rolling over keys, it starts to get complicated. It's going to require powerful tools in order to help people. And in some cases, organizations have homegrown administrative tools that cannot easily be adapted no accommodate DNSSEC."
Vixie says DNSSEC should allow the freedom to add new kinds of data to DNS--even data that cannot be corrupted such as encryption keys. But first, the infrastructure must be secure. "We have to secure what DNS has always done, and secure DNS internally. That's the primary purpose for DNSSEC from my point of view," he says.
Starting on here, we lay out in detail the essentials--some of them basic--every CISO must master. We're calling this one the Know-It-All issue, and we break down the components to stuff you Need to Know, and stuff that's Nice to Know. So in the spirit of this special issue, consider DNSSEC something you need to know, and something that needs to happen.