By MICHAEL S. MIMOSO
There's a certain Energizer Bunny quality to the Domain Name System. It just goes and goes and goes, usually without much maintenance. Problem is, while it's hassle-free, DNS usually isn't very secure.
Last July, researcher Dan Kaminsky exposed DNS' worst-kept secret. His now famous cache-poisoning bug turned DNS--best known for translating human readable domain names into IP addresses that servers understand--into center stage of the computer security world. The little protocol that could was quickly the biggest problem on the Web. Suddenly, it was relatively easy for attackers to redirect requests to malicious websites where phishing attacks or SQL injections awaited.
And aside from an ambitious patching effort, coordinated by Kaminsky, and pulled off by a gaggle of vendors including Cisco, Microsoft, the Internet Systems Consortium (ISC), and others, there was little in the way of a permanent fix.
His bug not only kicked off a firestorm of publicity and new disclosure debates, but it cast a glaring light on DNS' shortcomings. It also renewed interest in DNSSEC, or DNS Security Extensions, which are a set of protocols that essentially introduce PKI to the Domain Name System.
DNSSEC is the cure to cache poisoning attacks in the DNS. No one argues the point. It won't fix all the security woes in DNS, but it does check one of the biggest threats to ecommerce and trust on the Internet. Implementing DNSSEC, however, is another matter. Not only does it require a significant infrastructure overhaul for large enterprises and service providers running DNS servers, but a host of political battles are keeping DNSSEC from reaching critical mass.
"DNSSEC is interesting not because it fixes DNS," Kaminsky says, acknowledging that until his bug was made public last July, the DNS protocol wasn't widely well understood; people knew that it just worked. "DNSSEC is interesting because it allows us to start addressing the core problems we have on the Internet in a systematic and scalable way."
POLITICS AND SIGNING ROOT AND TOP-LEVEL DOMAINS
DNSSEC is not new. It's been around for the better part of 15 years, but every single iteration of DNSSEC has run headfirst into oblivion; beaten down by complexity and scalability issues. DNSSEC promises to protect the Internet against cache poisoning attacks such as Kaminsky's (it does not guarantee confidentiality, nor does it protect against denial-of-service attacks). Attackers can poison a DNS cache by exploiting a flaw in the system that prevents a DNS server from validating a website request. Incorrect entries are cached instead and served to others trying to reach that website. Those users are then sent to the attacker's site where the user is infected by malicious code or tricked into giving up personally identifiable information.
DNSSEC counters that possibility by implementing digital signatures and encryption to DNS lookups. Each lookup adds four new resource record types to a request, according to the dnssec.net website: a resource record signature; DNS public key; delegation signer; and Next Secure, or NSEC. DNSSEC verifies whether the respective keys match the information on the sender's DNS server. If not, the request is dropped.
If it sounds complicated, it is.
But that doesn't lessen the need for it, according to many. In fact, the DNSSEC movement is gaining momentum. Most recently, the .org top-level domain was signed with DNSSEC, joining the .gov TLD, which was signed earlier this year. Sweden's .se top-level country code domain has for years been signed, as have some banking domains in Brazil. DNSSEC, however, won't reach Jon and Kate proportions of critical mass until the .com domain is signed, as well as the Internet's 13 root zone domains.
"You need root signed, you need .com signed; bottom line," Kaminsky says. "Right now, .org is more secure than .com. That is not a situation that can remain in the long term. [Signing] .com is huge, major technology."
VeriSign controls the .com and .net domains, as well as two server clusters that make up root domains. IANA (Internet Assigned Numbers Authority) managed IP address allocation and manages the root zone. IANA, a subset of ICANN, decides what goes into the root zone, DNSSEC included, and works closely with VeriSign which manages the server clusters that produce daily zone files that are passed along to name server operators.
VeriSign announced in February that it would sign .com with DNSSEC by 2011. Many expect the signing of .org and .gov with DNSSEC to further illuminate the need to shore up DNS security (see "PIR Moves Cautiously with .org Domain Signing," p. xx).
"Having the top-level domain signed is really important, but really, the most critical thing is having the root signed," says Ram Mohan, executive vice president and chief technology officer of Afilias, service provider for the .org domain. "Having the root signed ensures that you can have a complete, trusted chain in the entire eco-system.
"Most of it has to do with how one looks at DNS. Today, DNS is incredibly vulnerable and pretty open to cache poisoning and the Kaminsky-type attacks in spite of all the patches," Mohan says. "If you don't' fix problem, I fear that in a short while, we're going to have attacks the size and scale we've never seen before. Signing the .org TLD is a symbolic and important milestone along the way."
While the technology challenges are steep, the political ones may be at a sharper incline.
"The amount of data at the root is small enough that signing it is no big deal," say Paul Mockapetris, the man who invented DNS in 1983. "The technology problems are trivial. The political problems are a mess."
Mockapetris, board chairman at Nominum, a network naming and addressing provider and original developers of BIND9 and ISC DHCP3, has watched DNSSEC wallow in discussions around standards and political tugs of war. The crux of the political issue is control over the encryption keys that will sign the root. Who holds the keys? What crypto systems and algorithms will be amenable to all nations? Digital signatures that work in the U.S., may not be acceptable in Russia or in Asia-Pac. Complicated questions all around.
"We need to figure out how to disperse authority and share control," Mockapetris says. "Having one authority based in one nation, you won't get longterm buy-in from everyone else. The problem with DNSSEC is that it is oriented toward having one party in charge, and they all think they should be." (See, "Call for Alternatives," p. xx)
Mockapetris fears that while the Kaminsky bug forced ISPs and enterprises to patch a serious vulnerability, that people won't be resolved enough to send necessary money and resources toward DNSSEC without an extensive, tangible attack.
"My personal position is that in order to get DNSSEC to happen widely, you have to have a billion-dollar attack," he says. "Right now, the message is still 'there's a vulnerability out there.' But people are more concerned with other things. I don't think [DNSSEC] was designed to make it easy to deploy. People have been at this for 15 years in many versions. To some extent, they haven't been able to make hard compromises to make it easy deploy. That is part of the problem as well."
COMPLEXITY, SCALABILITY IMPEDE DNSSEC DEPLOYMENTS
Many large enterprises run their own DNS. Many companies outsource their DNS needs to a service provider. DNSSEC is gaining momentum in verticals such as financial services, telecommunications and the government with .gov. Deployments in the U.S. are expected to ramp up as products mature and help automate deployment and key management of DNSSEC.
Unlike DNS, which can essentially be set and forgotten, DNSSEC must be babysat. There are free and open source tools available for an enterprise that wishes to deploy DNSSEC manually.
"You have to generate keys; you have to insert the keys into a zone file, sign the zone and then push signed zone to slave servers," explains Mark Beckett, vice president of marketing for Secure64, a provider of zone signing and key management software.
When cryptographic signatures are generated, they are good only for a certain period of time. They must continually be re-signed and frequently (weekly or more frequently) regenerated. Key values must be changed and key rollovers done periodically.
"If you run your own DNS, you have a lot of options already. You can secure it tomorrow depending on how thorough you want to do it: you can go to extremes and buy a hardware security module to store keys, and develop procedures to secure keys," says Shane Kerr, BIND 10 program manager for the Internet Systems Consortium, which manages BIND, the most common DNS software in use today.
"For the average organization, you don't need to be more secure with DNS than you do with Web pages. If you run SSL on a page, you probably want to look into DNSSEC as well and leverage existing procedures to have similar levels of security," Kerr says. "It depends on the type of technology you use; if you run BIND, you can use DNSSEC out of the box; plus there are a number of commercial products you can buy that run DNSSEC."
All of this adds operational complexity.
"It's not just set it once and forget about it," Beckett says. "This is a big break from the way we tended to manage DNS in the past. With DNSSEC it's a much more active process."
That means educating DNS operators and registrars, some of whom are not incented enough to pursue DNSSEC because they offer free DNS to customers, to understand the security issues and responsibilities associated with managing DNSSEC.
"Simplification is the key here," says Afilias' Mohan. "We hear complaints about how geekified DNSSEC is; keys, zone signing and key rollover. These are mind-numbing terms. What is the real benefit? That has been missed."
"The situation was that this is another solution in search of a problem. The Kaminsky vulnerability defined the problem. We've got to get to the point where we clearly explain this solves DNS hijacking, not data integrity not data confidentiality, not phishing, not pharming. This ought to be a straight line. Everyone is going to have to face this problem of having their domain traffic hijacked. If we solve it with one good solution that works well, it's DNSSEC."
Kerr says ISC's next release BIND 9.7 aims to simplify DNSSEC use.
"Right now, the software implements all of the standards, but not in an easy-to-use way," Kerr says. "One of big hurdles is that this is something you don't want the average admin to have to configure. There's a lot of work with UNIX command lines and ugly crypto strings that don't fit on the screen. We're hoping to make that simpler."
Beckett says large service providers such as cable and broadband providers are asking specific deployment questions around DNSSEC. Some began piloting DNSSEC in the months following the Kaminsky bug disclosure and are trying to understand some of the operational issues around deployments.
"What I'm seeing is some of the bigger service providers actively looking for ways they can offers secure DNS services to their federal customers first of all," Beckett says. "Some have broader horizons than that. Large cable or DNS providers are worried about consumers and how to protect them as more zones and domains become signed."
DNSSEC AS A BUSINESS ENABLER
Dan Kaminsky sees a bigger picture with DNSSEC.
He sees it as the cornerstone of Internet trust and the springboard for a new wave of products that scale across organizational boundaries in a secure way.
"The reality is that trust is not selling across organizational boundaries," Kaminsky says. "We have lots and lots systems that allow companies to authenticate their own people, manage and monitor their own people and to interact with their own people. In a world where companies only deal with themselves, that's great. We don't live in that world and we haven't for many years."
Data in the Verizon 2009 Data Breach Investigations Report [http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf], released in April, indicates that 60 percent of hacks are due to authentication flaws, usually around passwords being stolen or ineffective. Still, passwords remain the most common authentication method because they work across organizational boundaries, and they scale well.
By putting DNSSEC into DNS, a system doing cross-organizational address management for 25 years, Kaminsky sees boundless opportunities for trust and business enablement. (Read this interview with Dan Kaminsky)
"DNS works. It's the world's largest PKI without the 'K.' All DNSSEC does is add keys. It takes this system that scales wonderfully and been a success for 25 years, and says our trust problems are cross organization and we're take best technology on the Net for cross-organizational operations and give it trust," Kaminsky says. "And that if we do this right, we'll be able to see every single company with new products services around the fact there's one trusted root, and one trusted proven system doing security across organizational boundaries."
Indeed, DNS does more than IP address translation. It routes email, VoIP traffic and even RFID traffic, for example. Kaminsky believes that DNSSEC will force companies to escape the current security paradigms that were designed for a single organizational boundary.
"How many people have bought products that worked great in the lab and for a few groups, and once they try to scale it out, oops it doesn't work and you've gotta shelve it," Kaminsky says. "I'm tired of that happening. I'm tired of systems engineered just enough to make the sale. I want to see systems scale larger than the customers they're sold to."
Kaminsky admits he wasn't always backing DNSSEC. But the research he did on DNS following the discovery of his bug made him realize the levels of connectivity between organizations that DNS affords and how with a relatively simple attack he could access volumes of Web-based data simply by corrupting DNS. He wants organizations to break away from password-based trust models and absorb the one-time cost on DNSSEC, and realize that cost can be amortized across every Web-based project an organization takes on.
"People will deploy insecure solutions if it's too expensive to deploy what is theoretically correct," Kaminsky says. "DNSSEC is not an insignificant cost, but those costs can amortize across products that will be policy, compliance and revenue sensitive across an organization. We can eliminate 30% of the bugs Verizon saw. That's huge. There's ROI right there. Right now, we don't have scalable ways to do this, therefore it costs money. If we fix this problem, money is saved. It's called a business model, it's a good thing."
The Domain Name System Paul Mockapetris built 25 years ago; wasn't meant to support all that it does today. Security, for one, he says, was left out on purpose with the expectation that as more engineers gained experience with DNS, more would be added on to it.
"I did the basement and the first two floors," Mockapetris says. "In the 25 years since, people have been adding stuff on top of it."
DNSSEC is one of those add-ons, and in the year since Dan Kaminsky's bug, it has taken on new meaning and importance as organizations and engineers see the frailties of DNS exposed before their eyes.
"It's been my opinion for a long time that DNSSEC is a good solution; it doesn't solve every problem perfectly, but it does solve the small problems it attempts to fix," says Afilias' Mohan. "It's a good solution for a defined problem of DNS hijacking."
Michael S. Mimoso is Editor of Information Security. Send comments on this article to firstname.lastname@example.org.
This was first published in July 2009