From the Security Experts

Home
February 11, 2009

"To Secure or Not Secure," That Is the Question!


By Chief Executive Officer



In the past, the common refrain about DNS was “if the DNS goes down, the network goes down.” This rallying cry motivated reinforcement of the DNS infrastructure. In 2008, with the discovery of the now famous Kaminsky vulnerability, there’s a new refrain; “if the DNS is compromised, everything on the network is compromised.” It is now very clear that a DNS failure that disrupts access to network resources is not the only risk. In fact, the greater risk is that the DNS is fully operational but compromised, happily answering domain queries with bad addresses and thereby subjecting applications and subscribers to completely hidden threats.

 
The DNS has performed extraordinarily well for 25 years, but given the emergence of threats such as Kaminsky’s, it’s clear that it is at risk. You can ask the question “To secure or not to secure?” but the answer is obvious. The real question is “How to secure?” As part of the answer, let’s do a quick survey of what security capabilities are built into the DNS.
 
DNS can use TCP or UDP as the transport protocol, although UDP is used in most cases (more on that later). UDP does not have any security protections.
 
The TTL built into DNS records can also offer some protection, since it bounds the time during which attacks can be launched. But Dan Kaminsky figured out a way to eliminate TTL as a barrier to cache poisoning.
 
DNS was originally designed with a Transaction ID (TXID), which is a 16-bit field that uniquely identifies a query between a caching server and an authoritative server. Sixteen bits used to be a lot of protection, but it isn’t anymore. Kaminsky made this abundantly clear when he demonstrated his attack could compromise a BIND server in 10 seconds! His attack barrages caching DNS servers with fake answers to questions to overcome the TXID defense.
 
UDP Source Port Randomization (UDP SPR) is a protection that was just added to the DNS to make it harder for an attacker to spoof DNS queries. UDP SPR adds 16 more bits of protection. In specifying UDP SPR, the technical experts focused on a solution that every vendor could implement quickly to provide some defense against Kaminsky’s attack. They recognized when they specified it that it was not going to be a long-term solution.
 
Unfortunately, there is a widespread view that UDP SPR “solves” the cache poisoning problem. But the experts’ concerns were confirmed when a Russian researcher announced that he had compromised the newly patched version of BIND. His results were publicized in the New York Times a day after Kaminsky presented his findings at the BlackHat Conference.
 
Finally, there is another vulnerability. The DNS protocol allows authoritative servers to offer “additional information” and “glue” records to assist in resolving queries. Attackers can abuse this as well; in fact, that is precisely what Dan Kaminsky did.
 
Where does this leave us? Kaminsky discovered some holes in the DNS and others are bound to emerge”. More security measures are clearly needed in every DNS server to provide an adequate level of protection for today’s Internet. Security experts universally acknowledge that the best defenses are deployed in parallel — all active at once — but fail serially. Think of a belt and suspenders!
 
Using this logic, technical experts have been actively exploring and implementing solutions that will give the DNS a couple of belts and pairs of suspenders. One solution is to take advantage of the improved security of TCP when a caching server senses that an attack may be underway because it sees DNS query parameters that don’t match. Switching to TCP takes the attacker out of the loop and forces him to restart the attack, only to discover that it will fail again. The only way the attacker wins is if he guesses the query parameters correctly the first time.
 
Another defense is to screen the answers coming from authoritative servers and ignore information that might benefit an attacker. This means that in the rare event an attacker gets past the first set of defenses, he still gets stopped cold because the fake IP addresses he wants to store in the caching server are ignored. This plugs a major hole Kaminsky found.
 
Security experts also acknowledge that information is always useful when attacks occur so network administrators can go on the offensive, tracking down the source of attacks and putting up even more barriers to stop them. Smart DNS servers are designed to store data about attacks, making the forensic work easier.
 
The job of securing the DNS is not done yet. The IETF is currently working to specify additional probabilistic defenses to make the belt holding up the DNS even stronger.
 
The IETF also undertook a major effort to improve DNS security many years ago. The original design of DNS did not include authentication of DNS servers. DNS clients (in a browser, phone, game console, and so forth) are configured with a server address and they just go! Caching DNS servers also don’t have any way to authenticate the authoritative servers they consult for “answers” to domain queries. They find an authoritative server, ask the question and accept the answer if certain parameters match.
 
Likewise, there is no cryptographic protection (encryption or signing) of DNS records today. When attackers spoof DNS answers they need to get certain parts correct, but the important parts — like IP addresses — can be altered to suit their needs. A caching server receiving an answer to a query has no way to tell if a fake IP has been substituted for a real IP in a DNS answer.
 
To address these issues, the IETF has spent 15 years of effort and countless man hours on something called, appropriately, DNSSEC. The result is a collection of 16 RFCs that define how DNS resource records can be protected with digital signatures. A one-sentence explanation does not even begin to do justice to the importance and complexity of DNSSEC, but the next column will.
 
For now, when thinking about whether to demand the best security for your DNS, please just do!
 



Edited by Greg Galitzine