Home / Blogs

Thoughts About "Protection Against BIND"

Paul Vixie

Imagine my surprise upon reading a BBC article which identified ISC BIND as the top security vulnerability to UNIX systems. At ISC, we have striven for a decade to repair BIND's reputation, and by all accounts we have made great progress. "What could this be about," I wondered, as I scanned the BBC article for more details.

It turns out that BBC was merely parroting what it had been told by SANS.

OK, let's see what SANS has to say:

Top Vulnerabilities to UNIX Systems (U)

U1. BIND Domain Name System

Ouch! So at this point I'm asking, "OK, what have we done wrong this time?"

U1.1 Description

The Berkeley Internet Name Domain (BIND) package has become the worlds most widely used implementation of the Domain Name Service (DNS). DNS is a critical system that facilitates the conversion of hostnames (e.g. www.sans.org) into the corresponding registered IP address.

Yeah, yeah, so far, so good. What's the problem, though?

Due to the ubiquity and critical nature of BIND, it has been made the target of frequent attack.

Ubiquity isn't a vulnerability, though… So, I kept reading:

Denial of Service (DoS) attacks, which generally result in a complete loss of naming services to Internet sites, have long plagued BIND.

Um. Actually, DDoS attacks do not plague BIND. In fact, DDoS attacks have nothing to do with BIND per se — a DDoS is an attack on a network, and will affect all services offered by that network, including web services like those offered by Amazon and Ebay. So, what can they mean? Are they among the many people who are confused about the difference between BIND (which is software) and DNS (which is a protocol and a service)? In other words, do they really mean that DDoS attacks have long plagued DNS?

If so, then the mystery actually just deepens. UltraDNS and Akamai both offer DNS services and both of them wrote their own software (so, they are not running BIND), yet both of them have been the victim of high profile DDoS attacks which affected very visible customers including Google. Why would SANS single out BIND as a DDoS target, when DDoS attacks are not against software, and recent DDoS attacks against DNS have not involved BIND?

So, still mystified, I kept reading:

Various other attacks such as buffer overflows and cache poisoning have been discovered within BIND.

Well, OK, they've got that part right at least. The BIND software that was part of BSD was terrible. And after wrestling with it for a decade, ISC decided to rewrite it from scratch. The result, BIND9, is pretty solid.

Although the BIND development team has historically been quick to respond to and/or repair vulnerabilities, an excessive number of outdated, mis-configured and/or vulnerable servers still remain in production.

By the above-quoted text, this whole article is due to older versions of BIND and mis-configured servers running BIND, yet the title of the article was simply "BIND Domain Name System". This seems somewhat disingenuous.

But I kept reading.

A number of factors contribute to this condition. Chief among them are administrators who are not aware of security upgrades, systems which are running BIND daemon (called "named") unnecessarily, and bad configuration files. Any of these can affect a denial of service, a buffer overflow or DNS cache poisoning.

Yes, that's all true. I heard someone from Microsoft say that if they could just get people to upgrade from Win/95 and apply published patches, the whole Internet would be safer. And that's also true. I don't quite understand SANS's reason for mentioning it, though. "Unpatched Or Misconfigured Software Is Unsafe" is not exactly headline news. But if they like that one, how does "Either A Democrat Or A Republican Will Be Next U.S. President" sound? It's disturbing, it's true, and everybody already knows it, so, "so what?"

But you've got to understand something — I know some people who work at SANS and those people — the ones I know — are not idiots. So, I kept reading:

Among the most recently discovered BIND weaknesses was a denial of service discussed in CERT Advisory CA-2002-15. In this case, an attacker could send specific DNS packets to force an internal consistency check which itself is vulnerable, causing the BIND daemon to shut down. Another was a buffer overflow attack, discussed in CERT Advisory CA-2002-19, in which an attacker could utilize vulnerable implementations of the DNS resolver libraries. By sending malicious DNS responses, the attacker could exploit this vulnerability and execute arbitrary code or even cause a denial of service.

I love this! Thank you, SANS, for helping to get the word out. We've been telling our vendors and our user community to stop running or shipping BIND versions containing these vulnerabilities for years now. Several years, in fact. Ever since we cooperated in disclosing and repairing those problems. But it's 2004, and those two vulnerabilities were published in 2002, so why would it make any sense to announce them in 2004? Are they still newsworthy?

A further risk is posed by a vulnerable BIND server, which may be compromised and used as a repository for illicit material without the administrator's knowledge, or in stepping-stone attacks which use the server as a platform for further malicious activity.

I hate this! Damn you, SANS, for making me remember the fictional State Science Institute and its condemnation-without-facts of Reardon Metal. For the record, there has never been an exploit of the kind you're describing in any version of BIND9, and there is no known exploit of this kind in the latest version of BIND8, or even the latest BIND4.

OK, so by this point in reading SANS's article, I'm angry, and I'm starting to think of the article as a "hit piece". But I kept reading:

U1.2 Operating Systems Affected

Just about every UNIX and Linux system is distributed with some version of BIND. The installation of BIND can be intentional for server purposes or unintentional in a general installation. A binary version of BIND is also available for the Windows platform.

It is widely considered to be good practice to run a non-authoritative BIND server on every host, for the purpose of caching-for-reuse all data fetched from the global DNS. And for the record, full buildable open source code is available for BIND on Windows — not just binaries.

"What can they be thinking?" is what I was thinking at this point. Onward:

U1.4 How to Determine if you are Vulnerable

Any DNS server running a version of BIND that was bundled with the operating system, should be compared against the current patches released by the appropriate vendor. If a running version of BIND is compiled from source from the Internet Software Consortium (ISC), it should be checked to ensure it is the latest version. Outdated and/or un-patched versions of BIND are most likely vulnerable.

All true, every word of it.

On most system implementations, the command "named -v" will show the installed BIND version enumerated as X.Y.Z where X is the major version, Y is the minor version, and Z is a patch level. Currently the three major versions for BIND are 4, 8 and 9. If on is running a BIND server built from source, one should avoid using version 4, opting instead for version 9. You can retrieve the latest source, version 9.3.0rc2, from the ISC.

Actually, the latest version is 9.3.0 (it's not just a release candidate any more). But it's sure nice to hear them calling us ISC. Just "ISC", though, please, and never "the ISC". (A lawyer told me to say that.)

A proactive approach to maintaining the security of BIND is to subscribe to customized alerting and vulnerability reports, such as those available from SANS or by keeping up with advisories posted at OSVDB. In addition to security alerts, an updated vulnerability scanner can be highly effective in diagnosing any potential vulnerabilities within DNS systems.

Or, interested parties could join ISC's BIND Forum, with or without the Advanced Security Notification option. You'll not only get the straight scoop on upcoming releases, you can help set our priorities, and help pay the production cost of BIND. We (ISC) are a nonprofit corporation, and BIND is completely free software — more free even than FSF/GNU/Linux, since it can be bundled or repackaged or otherwise redistributed with or without source code, and with no license or royalty payments of any kind.

Or, interested parties could engage ISC in a support contract for BIND, which would include several of the above-described benefits of the our BIND Forum, but would also get you high-quality phone/e-mail support.

(I'm not just setting the record straight — a lot of folks just don't know about ISC's BIND Forum and BIND Support offerings.)


U1.5 How to Protect Against It

OK, wait just a minute. They've got a section entitled "How to Determine if you are Vulnerable" and now one entitled "How to Protect Against It" and the "it" in question is (from the title of this article) "BIND Domain Name System". Do folks really need to determine if they are vulnerable to BIND? And, for that matter, do folks really need to be protected against BIND?

But I digress. Fortunately we're almost at the end of this thing. Onward:

To generally protect against BIND vulnerabilities:

Disable the BIND daemon (called "named") on any system which is not specifically designated and authorized to be a DNS server.

This would be a mistake. If your local DNS policy makes every workstation and every server into its own "caching recursive forwarding name server"
then you are helping yourself and helping the Internet and you shouldn't stop just because SANS tells you to. But one of the other things they recommend is a great idea:

Apply all vendor patches or upgrade DNS servers to the latest version. For more information about hardening a BIND installation, see the articles about securing name services as referenced in CERT's UNIX Security Checklist.

For patches and checklists, you can also just visit ISC's BIND Home Page at <http://www.isc.org/sw/bind>. ISC publishes links to useful things about BIND configuration, even if they originate elsewhere.

To complicate automated attacks or scans of a system, hide the "Version String" banner in BIND by replacing the actual version of BIND with a bogus version number in the "named.conf" file options statement.

This is just foolishness. Any attacker whose age is requires more than one digit to describe will just "fingerprint" your system, including your kernel and all of your services including DNS. They don't need to know what version string you report, and they wouldn't believe it, and they've stopped asking.

And SANS ought to *know* that; moreover, they ought to be telling *you* that.

Permit zone transfers only to secondary DNS servers in trusted domains.

That's passe. Don't restrict zone transfers based on server IP address; instead, restrict them based on TSIG keys. (SANS ought to know that, etc.)

Disable zone transfers to parent or child domains, using delegation and forwarding instead.

I'm not sure what this means but I think I don't like the sound of it. You should not do anything special about parent or child domains — just create them, properly delegate them, and let DNS figure out where they are and how to reach them.

Jail: To prevent a compromised BIND service from exposing ones entire system, restrict BIND so that it runs as a non-privileged user in a chroot()ed directory. For BIND 9, see: http://www.losurs.org/docs/howto/Chroot-BIND.html

This is a great idea, which is why we have it as a standard BIND9 feature, and why we describe it in the standard BIND documentation.

Disable recursion and glue fetching to defend against DNS cache poisoning

I think that what they mean is "don't run authority service and recursive service in the same name server", and this is good advice. It's so good in fact that we wrote about it in , specifically ISC-TN-2002-2. Yup, two years ago. I guess it isn't news?

To protect against recently discovered BIND vulnerabilities:

For the Denial of Service Vulnerability on ISC BIND 9:

I'm sorry, I know this sounds catty, but… 2002 is "recent"?

Multiple Denial of Service vulnerabilities on ISC BIND 8:

Better still, just don't run BIND8 now that BIND9 is solid. But the URL they give makes good reading, even if I do say so myself.

Cache poisoning via negative responses:

OK, to give SANS credit, they found something that's less than two years old. However, it's in BIND8. Oops. You should all upgrade to BIND9 now. Even FreeBSD now ships BIND9 as their default name server. BIND8 is dead! Long live the king!

There exist many excellent guides to hardening BIND. One excellent guide on hardening BIND on Solaris systems, as well as additional references for BIND documentation, can be viewed at Running the BIND9 DNS Server Securely and the archives of BIND security papers available from Afentis. You can also view documentation covering general BIND security practices.

Those are good articles. But Jacco's site at <http://www.bind9.net/> is also very good, and includes all kinds of useful links. Education is good.

Administrators can also look at alternatives to BIND such as DJBDNS located at http://cr.yp.to/djbdns.html.

OK, so some of you were wondering why I bothered to respond to this obvious "hit piece" written by someone without much background in the field — maybe the same yet-to-be-fired marketing wizard who came up with the name "Internet Storm Center" when the term ISC had another, much stronger, much older, meaning. I was going to Just Hit Delete — something you should never do with spam, by the way! Until I saw the DJBDNS reference. Mr. Bernstein has what could politely be called a grudge against… well, almost everybody. His software seems to work, and it has a loyal and committed user base. But if you're going to look at alternatives to BIND, you need more options, and you need a better reason.

For more options, check out Nominum's ANS and CNS products, and NLNetLabs' "NSD", and Cisco's DNS/DHCP Manager, and Microsoft's Advanced Server product. (I'm sorry if I'm leaving somebody out, that's off the top of my head.)

For a better reason, discard "I don't want to have to learn about patches and apply them every year or two" since no vendor will ever be able to guaranty this. If you want help staying patched, talk to ISC about BIND support, or talk to your operating system vendor, or talk to your ISP. Help is out there.

My faith in and charity toward SANS has taken a sharp step downward today.

Paul Vixie
Maintainer/author, BIND4.9 - BIND8.1
Co-founder and President, ISC

By Paul Vixie, CEO, Farsight Security. More blog posts from Paul Vixie can also be read here.

Related topics: Cyberattack, Cybercrime, DDoS, DNS, Security, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


Re: Thoughts About "Protection Against BIND" Alec Berry  –  Oct 13, 2004 8:14 AM PDT

Thanks, Mr. Vixie. I was a bit shocked at the very same article. I manage a small number of domains (50), yet we have three BIND servers (on different networks), all running version 9, with none of the vulnerabilities mentioned in the BBC article. I have not found this difficult-- in fact upgrading or installing BIND 9 has been quite simple. Running it in a jail and observing all of the other security measures is only slightly more work, none of it difficult. There is more than ample documentation, including examples, shipped with the distribution. In other words, no excuses!

I remember the "repository for illicit material" alert from some time ago, and trying (to no avail) to find ANY detail so I could check my systems. I think the concept of SANS is a good idea, but to realize their potential, they need to maintain credibility.

Re: Thoughts About "Protection Against BIND" vortex  –  Oct 13, 2004 9:24 AM PDT

Dear Paul,


It's no consolation, but IMO, the section on MTAs contains very similar flaws.

Reading the description of sendmail:

"Sendmail has had a large number of vulnerabilities in the past. These vulnerabilities have often been due to its complexity. These have made Sendmail one of the most exploited services on the Internet."

vs that of Qmail:

"Qmail is a secure MTA that has had few vulnerabilities in the past. It is also one of the most popular MTAs after Sendmail."

The slant of the author does seem to again criticise and highlight past (and since addressed) vulnerabilities of the most popularly deployed agent, without underlining the many best practise issues you raise in your above response.

On top of that to describe other agents (including DJB's Qmail) as "secure" in such a context, raises further issues of impartiality.

The tireless Eric Allman should have similar cause to review his faith and charity towards SANS.

It makes me wonder whether these reports are in any way peer reviewed?

Regardless, to Eric and yourself, and the many others who contribute to such software projects with such rigour, thank you.



Re: Thoughts About "Protection Against BIND" Jeffrey A. Williams  –  Oct 13, 2004 7:02 PM PDT


I believe, as you know, that ISC has done a wonderful job to address past problems with Bind with respect to security. 

However I believe SANS is directing a broader audiance in it's concerns which are mostly concerned with older unpatched versions of BIND that many are still using/running.  Many of these organizations are registries and ISP's which seem to not be as effective or reasonably concerned enough to take the time and effort to upgrade.

Re: Thoughts About "Protection Against BIND" Jonathan Day  –  Oct 13, 2004 10:15 PM PDT

A fascinating article, highlighting the more "interesting" perspectives offered by less balanced viewpoints. On the one hand, it is very right and proper to highlight genuine concerns. It is a valuable, almost essential, reality check.

When, however, this vital tool is abused, it weakens vital lines of trust. Can you trust "security reports" if there is a high risk of them being bogus? Can you trust software watchdog groups if they don't verify their facts?

Sure, I know people who don't update software. I've seen commercial organizations happily run horribly early versions of software. BIND 4? Sendmail 6? Provided they'll actually run, people use them. "If they're not broken, why fix them?"

The problem is, they are broken, just not in ways that are immediately obvious. Therein lies the problem, and the dangers of negative advertising presented as a serious article. A program can run but still contain flaws that endanger security or trustworthiness. Unfortunately, your average Joe and Jane Average are not computer security experts. They don't know how to identify when software does contain such problems, so when they are told such problems exist they generally either do nothing or panic.

Institutes such as SANS are fully aware of this. This is why academia has long insisted on peer-review. It's not fool-proof, by a long way, but it cuts back on the more blatant abuses of the published media. When I want raw, unfiltered opinions, I can visit a weblog or a place such as Slashdot. If I go to a professional security institute, I expect something a little more solid.

To finish up, I'll make a point that I've made on other boards, elsewhere. The vast majority of software out there has security flaws. It is possible to eliminate them entirely, but that doesn't make it practical. Worse, the only way to never reintroduce bugs is to never add or change any code, so the only way to be completely secure is to be completely stagnant.

Usually, the sensible choice is to steer towards software that is getting lots of eyeballing and auditing (and therefore is reasonably safe to use), but at the same time is expanding to cover next week's or next year's needs.

Unless there is a specific requirement that can only be met by a package that is little known or may not be adequately reviewed, the prudent choice for the workplace is to aim for a solid foundation first and work out from there. An ounce of prevention is better than a tonne of cure.

As far as ISC products are concerned, I don't think I've ever had many security concerns. Irritations over a few things I'd have liked them to add, sure! Plenty of those. But since they're not writing specifically for me, that isn't likely to change anything. Besides, it's not as if I've written the changes myself and sent them patches. If I had, I might even have a legitimate reason to grouse.

But security? When was the last time you heard of a security hole in OpenBSD? Guess whose nameserver software they run? Then I don't think it's likely there are too many problems, then.

Re: Thoughts About "Protection Against BIND" Matt Crawford  –  Nov 09, 2004 9:03 AM PDT

SANS has published something stupid more than once.  I had a protracted semi-private argument with them in June 2000 about their recommendation that ICMP unreachables be blocked - no exception for "fragmentation needed." And government agencies were trying to rubber stamp the SANS word as policy. This was a crisis for some of us, and it took quite a while to get SANS to understand PMTUD.

Re: Thoughts About "Protection Against BIND" Gregory Miller  –  Jul 17, 2007 10:07 PM PDT

Thank you for a "tour de force" reply, which provided me a nice review, refresh, and update on BIND and DNS.  I am concerned about the SANS report and (lack of?) peer reviewing materials from what I expect to be an organization that conducts itself in a professional manner.  Its frustrating enough for everyone from network administrators to Internet strategists to stay on top of what's real vs. what's "spun." Your passion for BIND is clear, yet I respect your ability to maintain objectivity in your responses to what seems like less-than-informed attacks on the integrity of BIND (9).  I wonder if SANS is reaching for a wider audience in its publications (as suggested I believe in an earlier comment) and in so doing practiced more "typical" news reporting than professional technical journalism (e.g., more peer-review like).  Please keep up your excellent work and vigil for accuracy in BIND information.

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Promoted Post

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Don't Gamble With Your DNS

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Facilitating a Trusted Web Space for Financial Service Professionals

MarkMonitor Partners with CYREN to Deepen Visibility into Global Phishing Attacks

Verisign Named to the Online Trust Alliance's 2016 Honor Roll

Dyn Partners with the Internet Systems Consortium to Host Global F-Root Nameservers

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year

Is Your TLD Threat Mitigation Strategy up to Scratch?

Sponsored Topics