On Thu, 18 Aug 2016, Christos Zoulas wrote: > The recent change of ISC/bind licensing from BSD to MPL for the next > release has provided us with an opportunity to re-evaluate the preferred > daemon status for NetBSD and DNS resolution.
Wouldn't the license change result in some kind of status change in the main NetBSD CVS code repo for bind? I thought there was some kind of penalty box for not having a BSD license, anyhow. > If you feel that this creates problems for you, let us know. Also you > should be able to use newer versions of bind from pkgsrc. I have used Bind since the 1990s. I worked as a DNS admin for a (very) large corporation in the mid-2k-naughts's. We used bind in that environment, too. So, I have a lot of administration experience with Bind (so my minor critiques are coming from many years of exposure). That said, I'm not a fan of bind. I have a lot of respect for ISC and the folks who've maintained Bind over the years. However, I see it in a similar light as Sendmail. I could care less how "old" something is. That has about zero bearing on it's quality. However, if there *are* parts of UNIX history that aren't pretty. Sendmail and Bind both have had way-too-many security issues. It got so bad with Sendmail that folks finally wrote it off (thank $deity). Sendmail and Bind both have ridiculously over-complicated configuration formats due to their scope creep and inferior initial designs vis-a-vis later competing projects who were able to learn from their missteps. I'm not trying to be overly critical. Folks got a lot of milage out of Bind and Sendmail and a good sysadmin can set them up relatively safely. I know, because I'm in that category. However, it's just WAY more pain than is necessary when much more Unixy (to everyone's horror, I don't consider Sendmail to be Unix-like much at all due to it's overuse of M4 macros, in fact, it's a bit heretical, IMHO). Bind is not as heinous in it's own space as Sendmail has been over the years, but it doesn't change the fact that it's over-complicated and nasty in light of competing projects. That's just my impression, though. YMMV. > We are not planning to de-support or remove bind for NetBSD-8 I'd welcome it's removal since, as you say, it's in pkgsrc and folks can still fetch it easily and keep trucking with it. IMHO, Unixy first-principles (as well as volunteer energy) should determine what stays and goes in the code tree, not "backwards compatibility". That's M$-like thinking, to me. One major reason to be "open source" is that you *can* recompile the source if you want to change your ABI or other breakable bits. Also, one of TNF's stated goals for NetBSD is "correctness". I'm sure we could all debate what that means, but I'd assert that if you have several choices, you should pick the one most coherent with your own goals (licenses, design, simplicity, etc..). Again, I do realize how incredibly subjective all that is. So, I'm only stating my own opinion. Having worked with Unbound a bit, I have to say that it seems like a much more secure and easier to manage choice than Bind at this point. To ISC folks changing the license my feeling is "Thanks for years of service, but we've got to part ways now." Bind has picked up a lot of features over the years. I wouldn't be surprised if it could do a few things that Unbound cannot do. However, those are definitely going to be edge cases. 99% of folks running DNS servers are going to be just fine. Those that aren't, well, you can go to pkgsrc and still get bind. So, that's not really a big deal. That's my $0.02. -Swift