Last month’s column talked about DNS security in general.

 

The original DNS design intentionally left out several features, including security, dynamic update, and others. We have known all along that the DNS’s only security was the addressing mechanism: When hackers can forge packets, we are endangered, and when they can intercept and forge packets, we have lost.

 

This column will cover DNSSEC, which has been extremely visible in the marketplace lately due to the increasing recognition of the vulnerability of the DNS and the strong desire to better protect it.

 

In the simplest terms, DNSSEC allows a caching name server (the name server a user talks to) to verify that the ultimate sources of responses it receives are authorized name servers, regardless of what networks and name servers handled the data along the way.

 

The baseline industry standard mechanisms (UDP (News - Alert) SPR, TXID validation) don’t do this today and have serious shortcomings that are widely known. Some vendors have gone well beyond the baseline industry standards to provide additional protections, which are discussed at the end of this article.

 

For now, DNSSEC merely imposes a stronger encryption mechanism as an overlay to the standard DNS resolution process. More specifically, DNSSEC defines how DNS records can be digitally “signed” using public key cryptography. In response to an address inquiry from a caching name server, a DNSSEC-enabled authoritative server sends back a record (such as an IP address for a website) and a method for obtaining digital signatures that provide a chain of trust back to the root of the DNS, with protections at every level of zone validation. This approach offers far stronger verification and ensures that records have not been altered in transit. It is analogous to a tamper-proof seal put on when a product is manufactured.

 

DNSSEC is very complex; it is defined in a number of IETF RFCs and several vendors have implemented the necessary features. But today there is limited real-world experience with DNSSEC, although that is changing somewhat. The U.S. Government has mandated that all U.S. agencies must deploy part of DNSSEC by December 2009 (they must “sign” their DNS zones), which has generated a tremendous amount of activity.

 

The challenge is that for DNSSEC to work, many DNS servers must implement it. For example, for www.nominum.com to be protected, the root, .com., and nominum.com zones must be signed; the requesting user must employ a DNSSEC-enabled caching server, and nothing in the network must cause trouble (many DSL boxes won’t pass DNSSEC data, for example). These important first steps are just the beginning in the long road to making DNSSEC a reality. And we still don’t know for certain what it is going to take from an operational standpoint to deploy DNSSEC across important domains like .com, where there is no controlling entity that can mandate, let alone oversee, deployment.

 

The government is not the only organization actively evaluating DNSSEC. Service providers also recognize their duty to safeguard the Internet and are exploring DNSSEC. A large service provider recently presented preliminary findings about its work with DNSSEC at a conference. Its experience is instructive because as a service provider, it has the technical skills to methodically work through obstacles and configuration challenges, and to document and measure results. This means its work is a reasonable reflection of the state of the technology.

 

This service provider reported that one of the key operational challenges is the largely manual configuration required – signing records, generating keys, maintaining and rolling over keys, and similar tasks. Few tools are yet available to simplify and automate the process. This issue is manageable in a lab, but less so at scale, even at a modest enterprise scale. As DNSSEC becomes mainstream, network staff with less experience will require tools that make configuration and management simpler.

 

Also, the service provider’s work showed that DNSSEC will have an impact on the performance of the DNS. More memory is required in the authoritative servers that store records, because the records are 5-9 times larger when they are signed. Additional caching servers will also be needed because DNSSEC is a more computationally intensive protocol.

 

These issues are not trivial and present some of the biggest challenges to wide-scale DNSSEC deployment, as many DNS servers already suffer from performance issues due to the addition of UDP Source Port Randomization last year. Additional changes to the network architecture and planning, plus investment in hardware, space in datacenters, power, and more could make DNSSEC a costly proposition in production environments.

 

There is much more interest in DNSSEC since the Kaminsky vulnerability hit center stage last year. Mainstream estimates are that the transition to DNSSEC will take three to five years. This raises an even more important question. What do we do in the meantime? How do we protect the DNS while we go through a long deployment cycle with DNSSEC? As important, what protection will DNSSEC actually provide the Internet community if and when it is widely deployed?

 

In the end, DNSSEC is simply a stronger mechanism to guard against a single attack vector with multiple variants – namely, a hacker spoofing an authoritative answer. DNSSEC does not guard against malicious domains, illegal domains, phishing sites, malware sites, and so on. These, like every other domain, can be signed under DNSSEC mechanisms.

 

In the meantime, DNS cannot rely on external systems like firewalls or IPS/IDS systems for protection, as DNS traffic passes right through these devices. The industry may have to evaluate other, less challenging, encryption mechanisms to secure DNS against this attack vector. Some vendors have already taken this step and implemented these mechanisms into their systems in the hopes of driving interim or alternative standards to protect DNS from a spoofing attack. I would urge all to quickly evaluate these alternative approaches as the collective Internet community continues to evaluate broad DNSSEC deployment options.