Flaws in DNS are giving rise to exploits that could make moving computing functionality into the cloud a risky proposition. Say you're using a software-as-a-service CRM offering. When a salesperson types your SaaS provider's URL, how do you know his browser is linked to the vendor's server, and not a rogue?

Consider the hijacking of Comcast's Internet portal, Comcast.net. In May, attackers gained access to Comcast's Network Solutions administrative accounts and redirected customers to a defaced page. It took several hours for the company to regain control of its domain. Had the attackers been more subtle, they could have inflicted serious financial harm on Comcast by intercepting customer data, rather than simply causing embarrassment.

Security of DNS, which for 20 years has underpinned the Internet's name resolution system, was thrust into the spotlight this year with the discovery by IOActive researcher Dan Kaminsky of a flaw that could have made hijacking a domain name a trivial exploit that took only minutes to execute. How real was the risk? It resulted in the largest simultaneous security software patch in Internet history in July, with 16 vendors with whom Kaminsky shared the flaw--including the major makers of DNS servers, such as Cisco, Microsoft, and Sun Microsystems--releasing their respective patches on the same day.

If we can't rely on DNS, it's a stretch to let business units access mission-critical applications over the Internet, or trust that sensitive data sent to SaaS providers hasn't been intercepted. This sentiment isn't lost on our readers: In our most recent cloud computing survey, security was by far the most oft-cited concern.

The best answer to date for alleviating the security risks posed to DNS is DNS Security Extensions, or DNSSec, a group of protocols that ensures the authenticity and integrity of DNS name resolution. DNSSec isn't perfect, but it could stop many of the attacks that have bedeviled DNS servers and that rely on redirecting users to sites of the attacker's choosing.

For now, companies depend solely on SSL when moving sensitive data into the cloud. SSL relies on digital certificates to authenticate servers and provide encryption. If the digital certificates are valid, SSL authentication will protect against spoofing. But if an attacker poisons DNS and redirects everyone looking for, say, citi.com to his server, he can then disable SSL for the login, and users will get no error message. Another caveat: SSL failures, such as expired or untrusted certificates and domain name mismatches, are too often treated as inconveniences--developers and users tend to ignore SSL certificate alert warnings.

DNSSec's role is to stop the attack before it gets to the point where the attacker can trick the user.

Ideally, DNSSec would ensure that users are connected to the proper site, while SSL would be used to authenticate the server. There is some movement in this direction. The U.S. Office of Management and Budget has set December 2009 as the deadline to have DNSSec deployed for all .gov sites, and the .org domain is gearing up for a phased rollout beginning in January.

But that's where adoption ends, for now. VeriSign has yet to commit to signing the two most populated top-level domains, .com and .net, which it controls, citing the sheer scale of the undertaking. Microsoft hasn't set a date for providing DNSSec software on clients or its own DNS server, and few service providers have deployed DNSSec-aware DNS servers.