Oct 26, 2007 (08:10 PM EDT)
Tech Road Map: Secure DNS? Not Just Yet

Read the Original Article at InformationWeek

1   2  
THE LOWDOWN
THE PROMISE
By using cryptographic signatures that can be validated by others, DNSSec ensures that host name address lookups are legitimate, authorized responses.

THE PLAYERS
The IETF developed the DNSSec standards, while Microsoft and the Internet Systems Consortium deliver the lion's share of DNS servers in use today. NIST and the Defense Department are promoting DNSSec guidelines. Also on board are top-level domain (TLD) operators like VeriSign for .com and .net; the Internet Infrastructure Foundation, which runs the .se domain; the TLD for Sweden; and nic.pr, which manages Puerto Rico's .pr TLD.

THE PROSPECTS
Lack of server and client support and no clear driver will slow deployment schedules. Many point to the U.S. government's Federal Information Security Management Act of 2002 as a leading driver, but FISMA applies only to some government agencies and doesn't require use of DNSSec.
Say you type a host name, like www.yahoo .com. How do you know the IP address in the response really points to one of Yahoo's servers and not a rogue?

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.

InformationWeek Reports

NAME AUTHORITY
The Internet Engineering Task Force's DNS Extensions working group has been focused on DNS security for close to 10 years, hammering out basic protocol changes. Currently, RFC 4033, 4034, and 4035 make up the core DNS Security requests for comment. The main goal of DNSSec is to provide authenticated DNS responses to queries using public key cryptography that can be validated by DNS clients.

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").

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.