In Part I of this article I set the stage for our discussion and overviewed the October 21st DDoS attacks on the Internet’s 13 root name servers. In particular, I highlighted that the attacks were different this time, both in size and scope, because the root servers were attacked at the same time. I also highlighted some of the problems associated with the Domain Name System and the vulnerabilities inherent in BIND. Part II of this article takes our discussion to another level by critically looking at alternatives and best practices that can help solve the security problems we’ve raised.

The Alternatives and Best Practices: What are the preventative measures?

When searching for ways to increase DNS awareness we can look to Dr. Stephen Crocker, Internet pioneer and Chair of the ICANN committee. He highlighted in a recent Computer World interview with Patrick Thibodeau, that good practice involves more diversity and a need for a wider set of implementations of BIND. His suggestion may be more important than ever considering that just last week security researchers discovered new vulnerabilities in BIND 4 and 8. In particular, they found that BIND 8 is vulnerable to two separate DDoS attacks. The first involves the way BIND 8 servers handle invalid DNS lookup requests and the other occurs when an attacker causes a BIND 8 server to cache SIG resource record elements with invalid expirations. “We know that many people are running obsolete versions of BIND, and the older versions have critical bugs,” said Crocker. Clearly, keeping up to date with the most recent version of BIND is a fundamental best practice that administrators should follow. But is the most recent version enough?

For example, the most recent release of BIND, version 9.2.2, is indeed a major rewrite of many aspects of the underlying BIND architecture. With regards to DNS security issues, BIND 9.2.2 offers increased vigilance by acting as an authoritative server for DNSSEC secured zones. In brief, the IETF‘s DNSSEC protocol is designed to stop DNS “hijacking”, as is the case when a hacker tampers with a site’s DNS information and misdirects users to an alternate server. Implications of such “hijacking” would involve hackers sending users to a ‘bogus’ website posing as the company’s legitimate site and possibly extracting confidential information such as credit card numbers or personal identification. Mark Kosters, VeriSign’s VP of Research and DNSSEC expert says, “We are glad to see that Incognito is integrating DNSSEC within DNS Commander. We see the deployment of DNSSEC as one of the most critically important enhancements on core security on the Internet in these times of increased hacker activity and consequent security awareness.”

Kosters does make a valid point; however, it is important to understand that DNSSEC may be years away from being fully implemented. So, in the short run, the fundamental shortcomings of BIND still remain. We are then left with the burning question, “What do we do in the meantime?”

Interactive Week’s Charles Babcock points out that, “With few exceptions, Web sites have such a server in front of them running BIND and directing traffic. The DNS server is typically outside the corporate firewall with minimal protection and, thus, is a frequent target for hackers since 80 to 90 percent of the copies of BIND in use contain one of a dozen known vulnerabilities.” For this reason, it is important for network administrators to be aware of proprietary BIND alternatives.

A lot of times, administrators use BIND because it is free and they’re either not concerned about reliability or not aware of the risks of open source software. With businesses becoming more dependent on both their internal network and Internet presence to operate efficiently, support customers, and drive new revenue, reliability and quality of service is critical. For this reason, enterprises and ISPs need to consider implementing proprietary DNS software that is available only as compiled code, which makes it more difficult to discover vulnerabilities as compared to open source code. Because DNS is based upon well-established standards, core DNS functionality is not an issue with proprietary solutions as long as they meet these standards. Solutions, such as Incognito’s DNS Commander, can be highly-extensible, robust, and cost-effective, domain management solution that are secure BIND/MSDNS alternatives. Also, proprietary solutions tend to have performance improvements, feature enhancements, and are easier to deploy and use compared to BIND. After all, these vendors need to have better product in order to maintain a successful business. Often, simply introducing a proprietary secondary DNS server as a backup to the network can greatly increase DNS resilience.

As an example, the UK Ministry of Defense recently communicated their need for a secure DNS solution. General Dynamics, the contractor responsible for the UK MOD’s BOWMAN project, evaluated several prominent DNS solutions, including BIND, as part of their selection process. It was concluded that, “Given the needs of the BOWMAN program, the proprietary DNS alternative that Incognito develops had the best fit in terms of features, reliability, and security,” said Andrew Greenslade, BOWMAN Product Manager at General Dynamics Canada. “Integrating a DNS alternative into the BOWMAN program will fulfill General Dynamics’ mandate to provide a secure, reliable, and robust DDNS solution.” With a deployment that includes thousands of administrators directly managing DNS in a possibly hostile combat environment, an easy-to-use management interface with superior redundancy and diagnostic tools are critical requirements that alternative solutions are offering.

Another DNS alternative includes taking advantage of a two-pronged solution. Radware, a Mahwah, N.J.- based company, points out that their Web Server Director (WSD) solution provides comprehensive IP application security and optimization. To illustrate, a combined solution would have a Radware WSD deployed between the Internet and several DNS Commander servers. The WSD would be configured with a Virtual IP address and root server databases are updated to point to this Virtual IP address (VIP) and other VIPs for redundancy. The WSD hides the IP addresses of the DNS Commander servers behind it, providing security from attacks, and WSD also load balances DNS requests across these servers for optimized DNS operation.

Aside from using a two-tiered virtual IP solution that works to prevent DDoS attacks from reaching the DNS server, many DNS experts assert that mirroring the root server data can also be a simple and cost effective way to secure that information. The Washington Post recently reported, “that many of the nation’s top e-commerce companies mirror information contained in the root servers to safeguard their operations from DDOS attacks.”

This is a valid point because firms that mirror root data will inherently be more secure because they will rarely need to query the root servers. In the case of a DDoS attack where the root servers are affected, a company with a root mirror will be able to continue daily operations and will likely not feel the effects of a DDoS.

Allan Liska, Security Engineer for Symantec’s managed security division, highlights that mirroring the root data is not overly complicated in BIND, but can still be very cumbersome and time consuming. “If BIND is running on a server with other services there could be a problem with not having enough space to implement it. On the other hand, if the company has a dedicated DNS appliance with more than enough storage space to hold the 30+ million records hosted on the root servers, it is a much simpler task.”

Looking Forward

Despite the current market’s lack of enthusiasm with technology, the greatest opportunities lie ahead solving the most pressing issues of the Internet - security, access, and identity. The most recent DDoS attacks have revealed a great deal about the vulnerabilities of DNS, and although experts assert that the next hackers attempting an attack will use this information for their advantage, it is also necessary to utilize such revelations for improving DNS security. Armed with such knowledge and increased public pressure, the stimulus to incorporate best practices in DNS management should be a number one priority on everyone’s security agendas. The warning signs are everywhere.