Who's Really at Risk From the DNS Flaw?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

With DNS so vital to the operation of the Internet, security threats to it need to be taken seriously. But when it comes to the recent disclosure of a multivendor DNS cache poisoning issue, who really is at risk? And will the Internet collapse if the issue isn’t fixed?

Experts say that while the new DNS cache poisoning issue is very serious, DNS has been threatened before — and the core structure of the Internet name servers remains ready for such challenges.

“This is the type of attack against DNS that we anticipated years ago would be theoretically possible,” VeriSign CTO Ken Silva told InternetNews.com. “And this is not the first instance of cache poisoning that has been reported, as there were similar issues in the late 90’s.”

Reports about the DNS vulnerability surfaced after Dan Kaminsky, director of penetration testing for IOactive, reported a design flaw issue with DNS that could allow for a cache poisoning attack.

The attack would cause a corruption on a DNS server, so that an end user would be rerouted to an arbitrary site. For example, a user could type in Google.com, but end up at a location of the attacker’s choosing.

Kaminsky described the flaw as potentially disruptive to the operation of the Internet.

While most industry insiders agreed that the flaw is dangerous, they also said that it’s impact may not be as great as had been feared.

As it turns out, the flaw does not affect all types of DNS servers. Authoritative names servers like those operated by VeriSign are not at risk whereas recursive name servers that may exist within ISPs and enterprises are at risk.

“VeriSign’s Atlas has never been vulnerable,” Silva said, referring to the main DNS servers for the .com and .net domains, which VeriSign operates under a multiyear agreement with ICANN.

“DNS is a hierarchical system,” VeriSign’s Silva explained. “It’s meant to have layer of queries. We don’t provide an address for www.microsoft.com, for example. We don’t provide that answer. We provide an answer that provides the names of the servers that would have the information.”

Neil Warner, Chief Information Security Officer for domain registrar giant GoDaddy, also told InternetNews.com that GoDaddy’s domain name customers are not vulnerable to the DNS cache-poisoning exploit.

Still, experts warned not to underestimate the problem.

“I don’t think that they’re blowing it out of proportion,” Cricket Liu, author of “DNS and BIND Cookbook” and a vice president at Infoblox, told InternetNews.com. “It sounds like it’s a
variation of issues we already knew about. We have known for some time that the message ID in DNS isn’t long enough at only 16 bits. If I had to guess, I’d say that Dan Kaminsky found a more effective way of exploiting the lack of randomness.”

The problem stems from the fact that many DNS servers are configured to accept recursive name queries from anyone. A 2007 study from Infoblox found that more than half of all DNS servers allow for recursive queries.

When properly configured, a recursive-caching DNS server helps reduce the total amount of network traffic involved in DNS queries, Silva said.

For instance, if there were 30,000 machines in a corporation, and all 30,000 had to ask where a Web site was located, by going though a recursive name server, only one has to ask and then the information is cached.

But experts said that recursive queries shouldn’t be allowed unilaterally because they can be used to relay requests to other DNS servers, enabling DNS poisoning attacks. Ideally, a recursive DNS server within an ISP or enterprise should only provide responses back to users within their own environments — and not blindly across the Internet to anyone.

“When we look around for DNS servers that provide recursion, we should find almost nobody,” Infoblox’s Liu said. “That’s because we’re just a random person — the only people that should provide recursion are our own name servers.”

Even with a properly configured recursive DNS, Liu said still could risks from DNS poisoning.

“If you know that Mail Server ‘A’ uses Name Server ‘B’, then you could probably figure out, using a carefully crafted e-mail through the mail server, how to get it to send a recursive query to the name server,” Liu said.

As a result, while the DNS poisoning issued disclosed by Kaminsky does not affect all types of DNS servers, it is an issue that could impact a great many of them.

Consequently, several vendors are taking steps to combat the threat. Microsoft included a patch for its DNS server as part of its Patch Tuesday update.

Cisco spokesperson Kevin Petschow told InternetNews.com that four Cisco products were vulnerable, since they were capable of acting as DNS servers and had a DNS implementation weakness that made some types of cache poisoning attacks more likely to succeed.

Cisco provided details in a security advisory, in keeping with its normal disclosure policy. It also advised customers about appropriate measures and patches to combat the problem. Petschow added that Kaminsky had contacted Cisco directly about the issue.

Cisco rival Juniper Networks also issued an advisory about vulnerable products.

“Most routers and switches are either endpoints on the DNS system, which do not make them targets for this vulnerability,” Barry Greene, director of the Juniper Networks Security Incident Response Team, told InternetNews.com. “It will make them ‘victims’ of the vulnerability — whereas the DNS server the router uses to query could be poisoned.”

Internet Systems Consortium (ISC) also released an updated version of the open source BIND server, which is widely deployed on Unix and Linux system.

In addition to the effort by vendors, patching vulnerable systems will still require some human intervention, according to Infoblox’s Liu.

“You’re going to have to do it yourself,” he said. “With Linux that might be relatively straightforward, but it will require at least a small amount of downtime.”

This article was first published on InternetNews.com.