IoT
Infrastructure
News
10/25/2007
04:45 PM
Mike Fratto
Mike Fratto
Features
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%
RELATED EVENTS
The Analytics Job and Salary Outlook for 2016
Jan 28, 2016
With data science and big data top-of-mind for all types of organizations, hiring analytics profes ...Read More>>

Tech Road Map: Secure DNS? Not Just Yet

Despite a real need, security extensions for the domain name system aren't ready for widespread use.

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.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
2014 Next-Gen WAN Survey
2014 Next-Gen WAN Survey
While 68% say demand for WAN bandwidth will increase, just 15% are in the process of bringing new services or more capacity online now. For 26%, cost is the problem. Enter vendors from Aryaka to Cisco to Pertino, all looking to use cloud to transform how IT delivers wide-area connectivity.
Register for InformationWeek Newsletters
White Papers
Current Issue
How to Knock Down Barriers to Effective Risk Management
Risk management today is a hodgepodge of systems, siloed approaches, and poor data collection practices. That isn't how it should be.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.