Trust net: How DNSSEC can make the internet safer | SC Media
Strategy

Trust net: How DNSSEC can make the internet safer

May 5, 2010

Adoption of DNSSEC is gaining steam, says Lauren Price, chairwoman of the DNSSEC Industry Coalition. Dan Kaplan investigates.

On a quiet Sunday two years ago, renowned security white-hat Dan Kaminsky was sitting in his Seattle apartment, fooling around with some software, as he often does, when he stumbled on a gaping hole in one of the internet's fundamental building blocks.

He discovered an inherent design flaw in the domain name system (DNS), a critical component of internet infrastructure that translates IP addresses into memorable domain names. If exploited, the vulnerability could have led to a devastating hacker technique known as cache poisoning, by which a cybercriminal directs users to the website of his choosing without the user even realizing it. There, they can be stripped of banking credentials, for example, or be forced to download malware. Such attacks, while rare, have happened. What's worse, no browser or operating system security solution can prevent a redirection at the DNS level.

“The terrifying thing to me about the cache poisoning vulnerability was not that that you could hijack DNS, but that it could matter so much,” Kaminsky (right) says now. “It was ridiculous that something that simple could be so dangerous. But as a foundational layer, when DNS goes, everything goes with it.”

Kaminsky, whose day job is director of penetration testing at IOActive, quickly realized how destructive his discovery could be, and his focus immediately turned to fixing the problem – and fast. The self-professed DNS geek was so concerned for the internet's health that he arranged a secret meeting among a group of researchers and technology providers on the Microsoft campus in Redmond, Wash.

The gathering resulted in the unprecedented, coordinated release three months later of a patch from dozens of vendors that make DNS servers and clients. The fix essentially extended the randomness of the source port in the DNS server, significantly limiting the chance of attack. But it didn't completely rule out the possibility. Kaminsky called the patch a Band-Aid.

A few months passed, and once the buzz around the flaw began to wane, Kaminsky – and others with a vested interested in DNS – began to think bigger, longer term and permanent. Their attention turned to DNSSEC, a set of Internet Engineering Task Force extensions that provide authentication of DNS data. DNSSEC uses digital, cryptographic signatures to protect against forged DNS data and ensures that the server to which a user believes they are connecting is the correct one. Meanwhile, website owners can benefit by ruling out the possibility of domain hijacking, in the process protecting their brand from reputational harm.

“We just didn't have an efficient way to exchange key material across organizational boundaries,” Kaminsky says. “Everyone uses DNS as the overarching system by which they can access each other's servers. It works amazingly well. It's been working for the past 25 years. But right now, all it gives us is connectivity. It can't give us trust.”

The rise of DNSSEC

The concept of DNSSEC was nothing new – in fact, development of the standard has been in the works for more than a decade. But nothing had prompted massive adoption – until Kaminsky's revelation, that is. Momentum started to build.

Now DNSSEC adoption appears inevitable, and the schema may usher in a new era of trust never before seen on the internet, says Lauren Price, chairwoman of the DNSSEC Industry Coalition, a group of registries and industry experts whose mission is to encourage implementation of the technology.

“Virtually everything on the internet today depends on DNS, and if you step back and think about that, it's pretty extraordinary,” Price says. “Without it, the internet does not work. When DNS was created for the internet, the principal players weren't thinking about how it's being used today. There's really nothing wrong with the infrastructure. What's wrong is the way it's being used and abused.”

Cache poisoning is much more menacing than traditional phishing, which is reliant on the victim falling for a bogus URL, she says. “It's actually more dangerous and smarter than phishing,” Price says. “You can really be on BankofAmerica.com, and someone is hijacking your traffic and taking you somewhere else.”

Yet what makes DNSSEC adoption particularly cumbersome is that for end-users and website owners to benefit, all members of the DNS chain must participate. These are the root, the top-level domains (such as .com and .org), and second-level domains (such as google.com), as well as internet service providers, which maintain DNS servers.

Each zone must be authenticated and signed through the creation of a public and private “key pair.” For the most part, involved parties have dragged their feet in deploying the standard. As a result, a chicken-or-the-egg dilemma has taken hold.

“Why sign [your DNS zone] if nobody is checking for signatures and vice versa?” asks Steve Crocker, CEO of internet firm Shinkuro and chairman of the Internet Corp. for Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee.

Someone had to step up to the plate. The first whiff of change in the United States arrived in August 2008, when the federal Office of Management and Budget ordered the .gov top-level domain (TLD) and all federal agency websites to be signed with the DNSSEC protocol.

But arguably the most crucial development came last fall, when ICANN, the organization charged with managing the DNS, announced that DNSSEC will be deployed at the root zone by July 1. The root zone, comprised of 13 root servers, is the top zone on the DNS hierarchy and lists the names and IP addresses of the authoritative DNS servers for all TLDs.

The next zone down is the TLDs, one of which, .org, will begin supporting DNSSEC in June, according to the Public Interest Registry, which manages the .org domain. The .com, .net and .edu TLDs are expected to follow suit later this year and early next.

Burden on organizations

Aside from the root and TLDs being signed, each individual, second-level domain must be signed. For DNSSEC to work, these website owners must embrace the standard, much like they have SSL to encrypt transaction data.
Now that momentum appears to be behind DNSSEC, domain owners are becoming increasingly interested. “At some point, it'll be part of good hygiene,” Crocker says. “If your zone isn't signed, people will look at you funny.”
Price, who works full time for the Public Interest Registry, cites several big-name websites, such as PayPal, that have realized the benefits of offering their customers a trusted internet experience. “Right now, you are vulnerable to people redirecting your traffic to somewhere you don't want to go,” she says.

But businesses wanting to deploy DNSSEC are reliant on registrars to deploy the standard. That is because registrars serve as the link between the domain and the registry. So far, 10 registrars have passed the required certification test to offer DNSSEC registrations, Price says.

Richard Merdinger, senior director of domain registration services at Go Daddy, which manages 40 million domains and is the nation's largest registrar, says the company plans a two-phase rollout of its DNSSEC services. The first phase allows website operators to generate a public and private key, known as a key pair, which they will use to sign their domains. Then, they can provide that information to Go Daddy, which will distribute the data to the registries. In the second phase, Go Daddy will manage the implementation on behalf of its customers for a yet-to-be-determined fee, leaving them with virtually nothing to do.

“It is our strategic plan to be offering the one-stop shop for DNSSEC,” Merdinger says. “The reason Go Daddy is doing this is we're hearing from our customers that they would like this support.”

Meanwhile, for larger organizations that manage their own DNS services, technology has evolved such that domain owners, using automated processes for key creation and management, can deploy DNSSEC themselves. An initial capital investment to upgrading or replacing one's DNS server would be required.

But the days of DNSSEC being considered too complex and error-prone to ever work appear heading toward the rearview mirror.

“The current barriers are no longer technical,” says Nathan Meyer, product manager at F5 Networks, a networking appliances company that makes a DNSSEC solution. “The current barriers are education and getting the word out. People have said DNSSEC is onerous, but you can get an automated system for a few thousand dollars.”

So where does all of this leave the average web surfer? After all, end-users are the ones making the DNS requests. This is where internet service providers come into play. Comcast, for one, plans to make its caching resolver DNSSEC aware by the end of next year, says Chris Griffiths, manager for high-speed internet engineering at the Philadelphia-based ISP. DNS resolvers are able to check if the information is identical to the information on the authoritative DNS server. That means Comcast will validate the DNS responses generated when a customer wants to visit a website.

“When a signed root happens, we would use that [cryptographic] key in our caching servers and use that to validate everything on the internet,” he says. “We're validating each step in the process of finding that domain.”
This is not to say that DNSSEC is a panacea. The protocol does not address every DNS security problem, says David Ulevitch, founder of San Francisco-based security firm OpenDNS. For instance, a cybercriminal managing a botnet may sign his central command-and-control server using DNSSEC, and it would appear as a legitimate domain.

“DNSSEC forces you to accept answers when maybe you don't want to trust some of those answers,” Ulevitch says. “To me, what's more important is deciding what's the good [sites] and what's the bad. I think people view DNSSEC as some utopian thing where every DNS security problem goes away. But bad guys can use DNSSEC too.”

Even so, OpenDNS plans to customize its DNS resolvers so they support DNSSEC in the future. In the meantime, though, the company already has added support for DNSCurve, a lesser known, somewhat competing standard that also closes the Kaminsky cache poisoning vulnerability. And, Ulevitch says, DNSCurve is easier to implement and manage. DNSSEC advocates, however, argue their standard offers a more complete, end-to-end solution.

Looking ahead

Now that technology has removed some of the burdens of DNSSEC adoption, Price foresees even bigger things coming. “Once we secure this piece, developers are going to start playing with this new toy, and a lot of opportunities could come of it,” she says. “So many applications and services are built on top of [DNS].”

For example, DNSSEC could be used to secure online health record distribution, she says. Or eliminate spam and phishing.

Applying trust to emails has long been the thorn in the side of the IT security community.

“The first thing every hacker learns is to be able to forge an email from somebody,” Kaminsky says. But attempts at ensuring that email senders are who they say they are, such as public key infrastructure (PKI), have been impeded by cost and scalability issues.

DNSSEC can confirm the authenticity of a mail server. “At the same time I'm getting the address of a mail server, I can get the key of a mail server,” Kaminsky explains. “The promises of PKI were always appealing. The technology we chose to implement those promises had some scalability issues, and DNSSEC solves those issues in a very elegant and powerful way.”

Kaminsky, initially concerned about the complexities of DNSSEC, is now one of its biggest proponents. And when this researcher says something about DNS, people tend to listen.

“It warms my heart,” he says of the standard. “We're actually going to be able to deliver a lot of functionality to customers that, really, we should have been doing for years.”

[sidebar]

How DNSSEC keys work?

Let's say you want to know for sure that something I send you can only come from me. In that case, I'll encrypt the data with my private key. Now in this case, the only way to decrypt that data is with my public key. Everyone knows my public key, so the intent is not to keep the data secret. But since the only way the public key will decrypt the data is if I encrypted it with my personal public key, you are assured that only I could have sent the data. In this way, you can validate that the data you have could only have come from me.

–  Nathan Meyer, product manager, F5 Networks

prestitial ad