Oct 26, 2007 (08:10 PM EDT)
Tech Road Map: Secure DNS? Not Just Yet
Read the Original Article at InformationWeek
You don't. In the past year, Symantec's DeepSight system reported 25 vulnerabilities on various DNS servers and resolvers. In fact, there are a number of ways DNS can be subverted to provide bogus information. An attacker could gain access to the DNS server and change records or use one of the many publicly available tools to forge a response. He could insert bogus information into a DNS cache or add false information to your computer's host name table, as we've seen with numerous worms and Trojans. Many of these attacks are difficult to pull off, and they're often short-lived and relatively easy to detect and correct. Still, while they last, damage can be done.
DNS is a simple, albeit large, hierarchy of zones. You can walk the DNS tree by reading a host name from left to right. For example, in the domain name www.example .com, www is the host name in the zone example. Example is a zone in com. Com is a top-level domain under the root zone. If DNSSec is used, a DNSSec-aware client could walk up the certificate chain and validate each DNS response as authoritative using public key cryptography. The assumption is that if private keys are handled securely by all zone administrators, the DNSSec-signed responses making up www.example.com will be validated. If an attacker attempted to spoof a forged reply, the forgery would be detected (see diagram, "Validating A DNSSec Request").
Normally, the DNS client on your computer, called a stub resolver, off-loads the DNS query process to a recursive DNS server that does the work of resolving a host name to an IP address, optionally caching the response, then sending the answer to the stub resolver.
Under the IETF's plan, stub resolvers that use DNSSec can off-load DNS validation to the recursive resolver, but communication between the stub and recursive resolver has to be secured. Using the IP Security protocol's Authentication Header between the DNS client and server is one method. Alternately, if the stub resolver is DNSSec aware, it can request all DNSSec records and perform its own validation. Because DNSSec has to be backward compatible, both options are supported.
All public keys in DNSSec can be distributed via DNS, except for the trust anchor. DNSSec can be used in instances where zones can be islands of trust, where the zone generates a key pair and signs its one public key.
The main stumbling block to global DNSSec deployment is a chicken-and-egg problem: A global DNSSec environment requires that the root zone be signed. All top-level domains, like .com, .net, .info, .biz, and .uk, also need to be signed. And all domains below them that want to leverage DNSSec need to--you guessed it--be signed as well. DNS zone managers now become involved in cryptographic key management. In addition, registrars like VeriSign and GoDaddy, which handle domain name registrations, will have to support DNSSec and secure registration processes.
And that's just to get DNSSec deployed initially.
On the client side, all the recursive DNS servers used by companies and ISPs will have to become DNSSec aware, because there's no point in deploying DNSSec if no one can use it. The stub resolvers used on desktops and servers ought to be DNSSec aware, but Microsoft has no plans at this time to build a DNSSec-aware stub resolver into Windows. Finally, to manage DNSSec, key management and distribution protocols, processes, and products will need to be developed and deployed.
That are a whole lot of moving parts, and if all lower-level components aren't on board, there's no compelling reason for TLD operators to go through the expense of rolling out DNSSec. What expense? Estimates say zone files might increase seven to 10 times in size, and bandwidth would be impacted.
In addition, as Ken Silva, chief security officer for VeriSign and an active participant in DNSSec development, points out, there are other, more pressing security concerns around DNS, including availability of servers, integrity of zone data, and securing DNS server software and operating systems. All of these have a greater impact on DNS than will DNSSec, in the near term, anyway.
While DNSSec is certainly desirable, the effort to roll out an island of trust within your own organization and the lack of a stub resolver to leverage DNSSec on the Windows platform, combined with the lack of a global DNSSec strategy, leaves no reason to pursue it--for now. When the tools become available and there's more widespread adoption, it will be another story.