Re: Securing bind..
This is well out of hand, and I've delt with it before, so this is my less
mailing on teh subject.
On Mon, 31 Dec 2001, Craig Sanders wrote:
> On Sun, Dec 30, 2001 at 08:34:32PM -0600, Michael D. Schleif wrote:
> > Craig Sanders wrote:
> > > On Sun, Dec 30, 2001 at 07:31:30PM -0600, Michael D. Schleif wrote:
> > > > ``By combining all these tools, you can finally approach the
> > > > functionality of a trivial rsync script. Wow.''
> > > >
> > > > Enough said . . .
> > >
> > > by throwing away all your existing zonefiles, DNS configuration, DNS
> > > tools and a bunch of features which djbdns doesn't support, you get to
> > > use rsync to transfer zonefiles around.
> >
> > And, perhaps, your point?
>
> that throwing away all your existing configurations and starting from
> scratch just to get a trivial feature (which can easily be had with a
> shell script wrapper around named-xfer) is NOT a good idea.
I am *NOT* suggesting that you use djbdns *just for* rsync zone transfers.
Either you're confused, which is OK, or you're pretending to have missed teh
point because you have nothing left to stand on.
These are my reasons for preferring djbdns, and mine alone.
1) djbdns is orders of magnitude smaller, simpler, and more elegant
than BIND will ever be. I believe that this makes it more likely to
be much more secure.
2) djbdns' file format is much simpler, and works much more like one now
imagines the DNS system itself. Very few sites need any real concept of
zones - we just don't setup dns like that.
3) djbdns is lighter - you only run the programs that do they things you
need, rather than running `djbdns --options`.
4) Following from above, djbdns has the Unix philosophy.
5) I find that I really like Daniel Bernstien's code. He's an excellent
programmer, and he really understands specifications, documentation,
and how to really define a good solution, and a coherent system. I
am not familiar with the group that codes BIND, but somehow they've
taken one of the Internet's simplest protocols, and made it the second
most difficult basic service to configure (the first, IMO, being your
MTA).
> there are two major problems with all of bernstein's software. the
> first is that it requires you to throw away your existing
> configuration...no big deal for a caching only name-server or if you
> only have one or two domains to serve. a severe pain in the arse if you
> have hundreds or thousands of domains.
This is crazy. Anytime you change software packages, you must rewrite your
configuration. And, if you or anyone you know manages thousands of domains,
I'll mail you a crisp, clean 20 dollar bill. (In order to be eligible, you
must provide the name of your employer, so that I can avoid their service.)
> the second is that it is incredibly inflexible - you can only use it in
> the particular way that bernstein wants you to use it...and if you
> actually need to use it some other way then you are, according to djb,
> an idiot because he is never wrong.
This too, is crazy. DJB desiged djbdns to work correctly. It does everything
that BIND does. Everything. No feature is left out, excepet the redundant
and archaic, which all have a newer, better solution. DJB sees a lot of
stupidity out there from the BIND zealots, and I don't see where he's wrong.
> bind is far from perfect. but it's a lot better than all of the
> alternatives. if something actually better (as opposed to just loud &
> grandiose claims of being better) came along, i'd switch to it in an
> instant.
I bet you wouldn't.
> > Broken as many of them are, they still work quite well with djbdns,
> > thank you.
>
> named.conf doesn't work with djbdns - a minor problem.
This is a stupid argument. httpd.conf doesn't work well with thttpd, and
proftpd.conf doesn't work well at all with wu-ftpd.
> more importantly, bind style zonefiles don't work with djbdns - the
> idiot invented his own stupid format for zone files. if djbdns had been
> "backwards-compatible" with bind zonefiles then it might have had some
> vague chance of replacing bind.
Perhaps, but BIND invented its own zonefiles too. What you fail to realize is
how bad BIND zone files suck.
> > > an additional part of the price you pay is djb's moronic non-free
> > > software license
> >
> > Really?
> >
> > <http://cr.yp.to/distributors.html>
>
> yes, really. non-free.
>
> if you don't understand WHY it's non-free then read the DFSG again.
This doesn't deserve a response.
> > > and his rabid
> > > reinvent-the-wheel-as-a-square-because-it-wasn't-invented-here
> > > attitude.
> >
> > As you know, the software does *not* espouse his nor anybody else's
> > views. So what?
>
> unfortunately, bernstein's software is severely limited by his views.
>
> he's a fairly good programmer....but a lousy systems administrator, with
> no concept of how real world sysadmins use tools or how they automate
> them.
I hope you don't consider youself a good systems administrator,
> > If conformance to standards is interesting to you, then check this
> > out.
>
> djbdns does not conform to standards. he proudly ignored any aspects of
> the standards that were inconvenient to him.
There is no RFC BIND!!! Christ, man...
> > > bind can do rsync zone transfers merely by writing a wrapper script for
> > > named-xfer. i've done it. it works.
> >
> > That, too, is my point -- glad you found it . . .
>
> so your point is that it's better to throw away years of configuration
> work so you can use djbdns than it is to write a simple wrapper script.
>
> right. good thinking.
-Tech
> craig
>
> --
> craig sanders <cas@taz.net.au>
>
> Fabricati Diem, PVNC.
> -- motto of the Ankh-Morpork City Watch
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: