CLOUDY, CHANCE OF STOLEN DATA
The trust that "I'm talking to the server I intend to talk to" is fundamental to the client-server model and becomes even more critical as organizations begin to move to SaaS and cloud computing, where IP addresses change while domain names stay constant.

From the perspective of a chief security officer considering letting employees send data to a SaaS provider, there's no way to ensure that a DNS response is accurate and coming from an authoritative source. That blind spot works to attackers' advantage in that, before they can eavesdrop on applications or manipulate conversations, they have to get unsuspecting users to connect to their servers. DNS spoofing--the ability to forge responses to DNS requests--lets attackers redirect users to servers they control by replacing a server's actual IP address in a DNS name lookup with an IP address the attacker controls.

The good news is, DNS hijacking of a popular Web site is difficult to pull off for any length of time. If a high-volume site, such as a large cloud computing provider, were hijacked, users would likely smell something fishy, and because of the sheer number of redirections to the false front, the legitimate site owner would be alerted. Similarly, an attack on a caching DNS server that serves a large number of users wouldn't stay secret for long. The side effects in either case will manifest as slow and broken connections on the user end, while the targeted SaaS or cloud vendor's site would see a precipitous enough decline in traffic that an investigation would ensue. Moreover, most attackers lack the sophistication to make a convincing forgery of a major site, just as phishers can't quite avoid mangling the English language.

Still, imagine the damage that could be done in even an hour of employees shipping customer data to a forged site during a busy period for your business. And highly targeted attacks may be less visible and therefore less detectable. A disgruntled employee could redirect traffic through a proxy server within a company's borders. That's far easier than redirecting the entire Internet--especially if the attacker has physical access to the network.

The DNS Security Extensions comprise a suite of standards that extend DNS to include features to sign and validate records using public key cryptography. Similar in concept to SSL, trust anchors at the root of the DNS, or at top-level domains like .com, .gov, and .org, sign the records in their zones. In turn, subdomains, such as example.com, example.gov, or example.org, sign the DNS records in their domains. Signatures indicate that records are authentic, from the authoritative zone. A DNSSec-aware computer or caching name server can verify that records are signed starting at the top-level domain and working down to the domain name you're interested in. If all the records check out, you have a verified DNS name.

In theory, DNSSec is fairly simple. In reality, the details are very, very messy. In practical terms, rollout of DNSSec will require new processes at every level of DNS and affecting every facet of domain management. For example, a policy framework governing how domain name owners will be verified and approved by registrars must be defined and enforced before DNSSec-protected domains are issued. After all, there's no value in signing domain names if you can't vouch for the authenticity of the owner. The process would need to be similar to how certificate authorities verify domain owners before issuing the Web server certificates used in SSL. Then, you need to do key management--always a fun process. In other words, a thorough vetting process is complex, labor intensive, and expensive.

YEAH, THERE'S AN APPLIANCE FOR THAT
Setting up DNS for DNSSec is complicated, but one vendor has stepped in to help. In June, Secure64 debuted Secure64 DNS Signer. DNS Signer is a hardware appliance, running Secure64's OS, aimed at managing all DNSSec key management and signing functions. The appliance runs on Hewlett-Packard hardware and uses the Trusted Computing Group's Trusted Platform Module to protect zone keys. Installation is relatively simple, requiring few changes to an existing DNS infrastructure. The claimed benefit is in a reduction in key and zone management tasks.

Still, complex changes may be required to a network to allow the DNSSec to function. For example, intervening network devices, such as firewalls that inspect DNS traffic, need to allow the DNSSec records to pass unhindered, yet DNSSec records are larger than 512 bytes and don't conform with DNS-size packets. This is primarily an issue with DNS proxy servers, which not only enforce how address port pairs pass packets, but may also attempt to verify that the claimed protocol, DNS, is conformant.

Caching DNS servers and DNS stub resolvers--the software on computers responsible for resolving names to IP addresses--also must be configured to support and verify DNSSec records, while at the same time accepting and caching unsigned DNS responses. To date, Microsoft hasn't given any indication about when, or if, it will support DNSSec in its host operating systems. Microsoft's DNS Server can cache DNSSec records, but not verify them. Without DNSSec-aware caching servers and stub resolvers, DNSSec is useless.

Finally, DNSSec won't be applied to every domain anytime soon, if ever, just as SSL isn't used by every Web site, only those that need authentication and encryption. The result is that there must be a way to tell applications that use DNS whether the requested domain name has been validated. That brings in a new wrinkle--how do you handle DNSSec-protected name resolution when there's a failure, such as an expired or untrusted response? With SSL, Web browsers give people the option to ignore the error. Given a choice, most generally make the wrong move and continue an SSL session even through it's invalid and therefore untrustworthy. Application developers face a Catch-22: Refuse to give the user the choice to continue potentially dangerous behavior and risk them finding a different Web browser that lets them do what they want, or let them make a dangerous decision.