Interesting view into the human elements of a software project.
BIND is one of those programs that scares the living crap out of me, both from a security perspective and from a complexity perspective. (Gee, could those be related?)
Just take a look at the list of BIND vulnerabilities. We're still finding em, and I'm sure we'll continue to for years to come.
BIND is one of those programs that scares the living crap out of me, both from a security perspective and from a complexity perspective. (Gee, could those be related?)
I couldn't agree more. I'm currently TAing a Bachelor Security course where I had to design some challenges for students to break into systems and one of them is DNS cache poisoning. I've spent the last few weeks digging into Bind's code, DNS implementation and old vulnerable versions and it's amazing how much stuff had gone ignored in the past and how many subtle vulnerabilities can hide for years in very complex software and protocols.
Note that djbdns wasn't vulnerable to the attack, because it was designed from the outset to exploit other sources of randomness. (I'm a little rusty here, but) The countermeasures djbdns employed against the attack were known all the way back when djbdns was started, and proposed on mailing lists before it. But BIND didn't employ them, because (I think, but could be wrong) that the BIND architects believed DNSSEC would be the operationally "correct" solution.
I trust djbdns more than perhaps any other piece of C code I run, and recommend it.
The last released djbdns is vulnerable to simple poisoning attacks however.
It does not merge duplicate queries, permitting infinite retries of spoofing
(just like Kaminsky's child label-NS replacement technique).
This failure undoes much of the benefits of source port
randomization. A patch is available from a third party, but it is not
part of the standard source tree.
http://www.your.org/dnscache/
There are also attack scripts for djbdns.
BIND, Unbound and other recursives have both SPR and duplicate
query control. This fact explains things like this:
http://dnsreactions.tumblr.com/search/djbdns
From a poisoning point of view, BIND and Unbound are more secure
than djbdns. To be fair djbdns is no longer maintained, so this poisoning
fix has not been integrated).
Security is relative. From a software coding point of view,
djbdns is smaller, has fewer features (e.g., ipv6 and dnssec lacking).
I.e., there might be coding errors in large code bases.
But for me, an unmaintained code base with known, unpatched
attacks is not a good choice.
If BIND is fairly vulnerable, why does everyone say it's the best/de-facto standard in Linux/DNS Servers? It's as if you use BIND & only BIND. Is it really that bad underneath?
You recommend something that hasn't been maintained in over a decade. Something that needs all sorts of random patches to still be useful? Random patches that may or may not introduce random vulnerabilities?
BIND may have had a (really) bad run in the BIND 8 days, but BIND 9 was surely an improvement.
And if you really want to stay away from BIND, you can go for something like PowerDNS. Or a combination like PowerDNS+Unbound.
I'm not sure what patches you're saying are required. Most startups don't need much more than what comes in the box. What's crazy to me is the idea that they'd opt into BIND 9 preemptively, not knowing what their extended needs are.
This is, for what it's worth, the original objection to qmail as well --- "it's not even maintained". It's not maintained because for the core job it does, it's _correct_. There's not a lot of mail software (at least, not software written in C) that can make a competing claim.
Best and defacto do not necessarily coincide. BIND is just one of those classics that have been around forever and have huge momentum behind them. BIND also powers many of the root servers afaik which gives it some extra credibility. But what is best for root servers might not be best for your average personal/small-business/startup use.
But bind is a fairly big and complex code base. Which is probably also tied to why people use it - it's got the features people need (and a _huge_ community and install base.)
Comments
Interesting view into the human elements of a software project.
BIND is one of those programs that scares the living crap out of me, both from a security perspective and from a complexity perspective. (Gee, could those be related?)
Just take a look at the list of BIND vulnerabilities. We're still finding em, and I'm sure we'll continue to for years to come.
http://www.cvedetails.com/vulnerability-list/vendor_id-64/pr...
For a refreshingly simple and secure DNS serving experience, I highly recommend djbdns / tinydns / dnscache:
http://cr.yp.to/djbdns/blurb/security.html
I couldn't agree more. I'm currently TAing a Bachelor Security course where I had to design some challenges for students to break into systems and one of them is DNS cache poisoning. I've spent the last few weeks digging into Bind's code, DNS implementation and old vulnerable versions and it's amazing how much stuff had gone ignored in the past and how many subtle vulnerabilities can hide for years in very complex software and protocols.
Kaminsky's DNS cache poisoning attack is fun.
Note that djbdns wasn't vulnerable to the attack, because it was designed from the outset to exploit other sources of randomness. (I'm a little rusty here, but) The countermeasures djbdns employed against the attack were known all the way back when djbdns was started, and proposed on mailing lists before it. But BIND didn't employ them, because (I think, but could be wrong) that the BIND architects believed DNSSEC would be the operationally "correct" solution.
I trust djbdns more than perhaps any other piece of C code I run, and recommend it.
The last released djbdns is vulnerable to simple poisoning attacks however. It does not merge duplicate queries, permitting infinite retries of spoofing (just like Kaminsky's child label-NS replacement technique).
This failure undoes much of the benefits of source port randomization. A patch is available from a third party, but it is not part of the standard source tree.
There are also attack scripts for djbdns.BIND, Unbound and other recursives have both SPR and duplicate query control. This fact explains things like this:
From a poisoning point of view, BIND and Unbound are more secure than djbdns. To be fair djbdns is no longer maintained, so this poisoning fix has not been integrated).Security is relative. From a software coding point of view, djbdns is smaller, has fewer features (e.g., ipv6 and dnssec lacking). I.e., there might be coding errors in large code bases.
But for me, an unmaintained code base with known, unpatched attacks is not a good choice.
If BIND is fairly vulnerable, why does everyone say it's the best/de-facto standard in Linux/DNS Servers? It's as if you use BIND & only BIND. Is it really that bad underneath?
I recommend djbdns.
You recommend something that hasn't been maintained in over a decade. Something that needs all sorts of random patches to still be useful? Random patches that may or may not introduce random vulnerabilities?
BIND may have had a (really) bad run in the BIND 8 days, but BIND 9 was surely an improvement.
And if you really want to stay away from BIND, you can go for something like PowerDNS. Or a combination like PowerDNS+Unbound.
I'm not sure what patches you're saying are required. Most startups don't need much more than what comes in the box. What's crazy to me is the idea that they'd opt into BIND 9 preemptively, not knowing what their extended needs are.
This is, for what it's worth, the original objection to qmail as well --- "it's not even maintained". It's not maintained because for the core job it does, it's _correct_. There's not a lot of mail software (at least, not software written in C) that can make a competing claim.
Having been through djbware patch hell, I tend to agree, but did he not finally actually open source his software (both qmail and djbdns)?
Has that addressed the patchiness blechery?
On rare occasion, someone actually finishes a program. Just because there aren't a mad rush of patches doesn't mean that a program is not up to snuff.
Best and defacto do not necessarily coincide. BIND is just one of those classics that have been around forever and have huge momentum behind them. BIND also powers many of the root servers afaik which gives it some extra credibility. But what is best for root servers might not be best for your average personal/small-business/startup use.
No, it isn't /that/ bad underneath.
But bind is a fairly big and complex code base. Which is probably also tied to why people use it - it's got the features people need (and a _huge_ community and install base.)