This article can also be found in the Premium Editorial Download "Information Security magazine: Why privileged account management is critical to today's data security."
Download it now to read this article plus other related content.
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
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. VeriSign declined to be interviewed for this article. 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.").
"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."
|A Call for Alternatives|
Some researchers are hesitant about compulsory use of DNSSEC.
THE DNSSEC BANDWAGON isn't completely full yet.
There are some holdouts who believe caution should be taken before diving headfirst into DNSSEC deployments.
"I think that DNSSEC is over-engineered and it's trying to impose PKI on DNS; there are advantages and disadvantages to that," says Ivan Arce, chief technology officer at Core Security Technologies. "If we use DNSSEC, it's not because it's the best thing, but because there is no other thing."
Arce raises concerns about complexity and the bloat of DNSSEC code intertwined with the political issues haunting deployments at the root and TLD levels.
"Part of this hesitancy around DNSSEC is that it heavily relies on crypto magic; when you have a security problem, sprinkle a little crypto on it, and it will be resolved," Arce says. "If you think about it, the paradigm it proposes is a thing of the past. PKI--it's very early '90s, and it didn't catch up. It requires a lot of code to implement it and a lot of operational overhead as well. It's also a business as well; there's money to be made on DNSSEC. I'm not saying it's not going to work, but I would rather see a more open discussion about alternatives."
DNSSEC requires an infrastructure overhaul, but not different than other overhauls enterprises are regularly faced with; the Kaminsky patch last year required a significant investment in time and resources to ensure it did not impact critical systems and applications.
"If there's a way to adapt the current protocol to enforce some basic security mechanisms and not boil the ocean to solve everything, I think that would be sufficient rather than changing the DNS infrastructure of the entire Internet," Arce says. "The point I'm trying to make is that we don't know how much discussion there has been about alternatives. Imposing PKI on that may solve some problems, but it's not a guarantee it will solve DNS security. There hasn't been an open discussion to do so."
In fact, the introduction of DNSSEC exposed a new security vulnerability known as zone walking. DNSSEC exposes private information about a network housed in the DNS. Attackers gaining access to this information would benefit from knowing the list of machine names in a particular zone; DNS is configured in such a way that users are not allowed to access this information. DNSSEC must be able to report when names are not found in a zone, therefore it must have access to the information.
The answer has been to use a protocol known as NSEC3 to obfuscate the contents of the domain, says Shane Kerr, BIND10 program manager for the Internet Systems Consortium [https://www.isc.org/downloadables/11]. Kerr says NSEC3 is leading edge technology; the .gov domain was signed with DNSSEC earlier this year and also used NSEC3. Kerr says there were instances where users had difficulty reaching .gov websites because of it.
"It requires more computation on the server side for queries," Kerr says. "Normal DNSSEC looks up a name and if it doesn't exist, you get a pre-computed answer signed back that it does not exist. With NSEC3, it takes a crypto hash of that query. If you look up ABC.com, you would not get the pre-computed answer, but you'd get an MD5 hash back."
Paul Mockapetris, the inventor of DNS in 1983, agrees that DNSSEC doesn't necessarily have to immediately be used on a wide scale. With DNS now routing email, VoIP phone calls and many other types of network traffic, why not push DNSSEC toward specific applications?
"Nothing says with DNSSEC that the whole space has to be signed," Mockapetris says. "We can figure out how to sign all phone or RFID data, or your own intranet. Most don't understand that a lot of DNS data on the Internet, billions of pieces of information, five times more of that is private behind firewalls. Maybe DNSSEC could catch on in limited contexts, then as we get more tools and experience, it could go more mainstream. That's my hope for it."
Arce, meanwhile, says DNSSEC goes against the open nature of the DNS. By adding PKI, you're essentially transferring control over it from the DNS operator to whomever controls the encryption keys.
"DNS problems have been known for a decade. There has not been as much visibility with policy makers or IT managers, but security experts have known DNS is broken, and known that for more than a decade," Arce says. "It's good that someone is actually paying attention, however I think the solution is not just to react and force compulsory deployment of DNSSEC."--Michael S. Mimoso
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."
|PIR Moves Cautiously with .org Domain Signing|
The Public Interest Registry plans up to a year of beta testing DNSSEC on the .org domain.
THE PUBLIC INTEREST REGISTRY (PIR), which manages the .org domain--the latest top-level domain signed with DNSSEC--says the move is a foundational element that will enable the development of secure applications and enhanced trust on the Internet.
"DNSSEC, as an extension to DNS, is the best way to authenticate sites effectively," says Lance Wolak, director of marketing and product management for PIR. "It's the best method because it extends DNS' capabilities; DNS is proven by far to be a great platform to build apps, and remains today a very open and sound architecture."
The PIR announced on June 3 that the .org TLD had been signed, and for the next six months to a year it will beta test DNSSEC extensions. It is the latest generic TLD to be signed with DNSSEC, .gov was signed in February.
"We're going out in a careful, responsible manner with the .org zone and testing DNSSEC with test domains that are not connected to actual live sites," Wolak says. "We'll start with test domains, and then once we are satisfied, we'll move on to public facing domains and continue to broaden that circle of what testing."
The PIR, which chairs the DNSSEC Industry Coalition, applied last March with ICANN to sign the zone with DNSSEC; that application was approved in June 2008. Along with asking for help from coalition members, PIR also reached out to other registries, including Sweden, that had done DNSSEC rollouts.
"We felt it was important to share implementation plans with others of similar interest," says Lauren Price, coalition chair. "We've gone as far to share our implementation guidelines across registries. This is an industry-wide upgrade to DNS; it's important to have a level of consistency in how we roll it out."--Michael S. Mimoso
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