BIND, the Berkeley Internet Name Domain, is the market share leader for domain name system (DNS) server software, with something like 85 per cent of installations worldwide. That’s getting into Windows’ market-share territory, so it’s hardly surprising that the software has received more than its fair share of security criticism over the years. Malicious hackers and white-hat vulnerability researchers tend to focus their efforts on the most widely deployed software. After all, it brings the quickest outcome for expended effort. In reality, open source software is already part of most IT infrastructure1, with little negative impact. Just like much of the Internet, open source has become both ubiquitous and essential.
Over the years, BIND has been criticized for the sheer number of software vulnerabilities that have been disclosed, and the relatively large number of software patches that have been issued to handle these bugs2. Vendors of competing products have shown this as evidence of the superiority of their own proprietary software, but clam up when asked to produce equivalent statistics of the number of bugs and exploits fixed in their products.
As Forrester Research’s Michael Goulde3 says, “North American companies are more likely to have embraced open source for mission-critical use. Companies are finding open source suitable for certain types of critical business applications.” We know now that the very openness of BIND has led to many individuals and companies examining each version of the product, discovering design problems and programming errors, and correcting them within days of discovery – a far cry from the traditional once a year upgrade cycle of proprietary software.
As a result, the open source nature of BIND has resulted in it being considered more secure than proprietary DNS solutions. After all, BIND gets updated an order of magnitude more frequently than its proprietary competitors, creating a much smaller opportunity for exploits to remain in the open.
Some say that malicious hackers have an easier time finding vulnerabilities in software when they have access to the underlying source code. But when one considers how vulnerability hunters, both white-hat and black-hat, go about the work of hacking into software, this is an unreliable argument. More vulnerabilities are discovered via probing and reverse engineering, trying to break into the software from the outside, rather than wading through the endless guts of programs, hoping to get lucky. Even relatively lightweight software such as BIND can contain tens of thousands of lines of source code. And it is likely that proprietary software has as high a propensity for vulnerabilities in it as open source BIND, if not more. Sunlight tends to be a great disinfectant, and that openness effect holds good in the software industry as well.
Consider the tools the good guys use to test their own security. While it is possible to obtain commercial or non-commercial software capable of scanning source code for potential vulnerabilities, these types of applications are far outnumbered by security tools and hacking programs that conduct “black box” testing against compiled or live code, in which the vulnerability scanner sometimes assumes the role of an attacker. One of the reasons for this is that analyzing millions of lines of source code is a considerably more challenging problem, even for software, than simulating known attack vectors to beat on the surface of an application until it breaks.
Take one of the most famous DNS vulnerabilities, the “Kaminsky Bug.” Did Dan Kaminsky spend months poring over source code to find the vulnerability, which had been sitting there undiscovered in all kinds of DNS implementations for years? No. He used Scapy, a network packet manipulation tool, to prod and probe for holes in production DNS servers4. What he found was essentially a hole in DNS itself, rather than BIND alone, but the principle remains: it is much more effective for vulnerability hunters to search the attack surface of live object code than its source. To put this in simpler terms, a burglar walking down a quiet street trying door handles will have a higher success rate than a burglar who spends all of his time studying the blueprints of a Yale lock.
To extend the analogy, if a homeowner has left their house unlocked for whatever reason, hoping that a burglar will not simply walk down their street trying handles, that person is relying on a principle known as security through obscurity. This notion, especially as it applies to cryptography, has been discredited by some of the world’s top security experts, starting with Auguste Kerckhoffs in the late 19th century5. Keeping source code secret and proprietary does not mean it does not contain vulnerabilities.
Proprietary solutions do offer several advantages – technical support, training, published upgrades, APIs, great user interfaces, etc. However, BIND, powered by the California not-for-profit Internet Systems Consortium, provides all of these features, albeit in the style of a not-for-profit organization. Perhaps the biggest thing that BIND does not offer is a targeted marketing message that reduces dissonance after a buying decision, which its proprietary counterparts do a great job of. When someone is on the phone congratulating you for spending your money on their product, sends you whitepapers and invites you to industry conferences that validate your decision, it is easier to defend the purchase, as compared to receiving security update after security update from BIND’s active mailing list. At the C-level executive suite, this lack of dissonance reduction is probably the single biggest reason why BIND continues to be replaced with expensive proprietary solutions once companies decide to invest more fully in a robust DNS infrastructure.
Of course, proprietary solutions also pursue a vendor lock-in model, where migration out of one solution to another is typically a painful and often troublesome experience. Combine this with an uncertain feature upgrade and release cycle and maintenance costs that tend to quickly be as much as the price of the software itself, the cost benefit analysis of BIND shows it to be a very attractive solution. In the case of open source software like BIND, which has a professional non-profit entity as well as an expert user/developer community behind it, users get some of the benefits of both worlds. When every user is also potentially a developer or patcher, the number of eyeballs keeping the code secure increases exponentially and the time to discover and resolve issues is drastically reduced.
Of course, at the end of the day, it comes down to accountability. If your BIND installation fails, who can you call? Is there dedicated support available to help configure your software, or do you need to troll through message boards and wait on email responses while your web site is suffering? User experience is varied here, but my suggestion is that for all mission critical software installed in your enterprise, you should secure proper support contracts and also train people in-house to ensure that you are not in trouble when a problem occurs, as it inevitably will. BIND provides how-to guides, a searchable database of problems, and may even provide training under contract.
Human beings are fallible, so all software is buggy and can have security vulnerabilities. It’s a fact of life that more widely deployed software like BIND is more likely to be attacked than less popular alternatives. It’s also a fact of life that BIND’s open source development process acts to minimize, over time, the total number of vulnerabilities, creating a much more resilient piece of software. We put our faith in it, and it has not let us down.
Disclosure: The author’s firm, Afilias, uses BIND software extensively in its global computer network and sponsors development and innovation of BIND software.