Re: DNS servers
overall, your argument is just a recapitulation of DJB's old favourite
"your way of doing things is completely wrong, you must throw it all
away and change to my One True Way". that may be enough to convince DJB
groupies, but it's not enough to convince me. in fact, it pisses me off
and makes me extremely reluctant to even experiment with his software.
feel free to dismiss all of the following as "just a question of habit"
because i'm absolutely certain that none of it will make any impression
on you.
On Wed, Nov 20, 2002 at 01:51:16PM -0200, Adriano Nagelschmidt Rodrigues wrote:
> Craig Sanders writes:
> > if djb actually gave a damn about providing a viable replacement for
> > bind then he'd climb down off his pedestal and implement native
> > support for bind-style configuration and zone files in djbdns. not
> > a translator, not a converter, but native support for the existing
> > files.
>
> I think the idea here is to have a file format that can be easily
> updated by scripts. For example, a script can monitor a cluster of web
> servers and change '+' to '-' in the record of a server that is down.
>
> Besides, I don't think bind's file format has anything special per se.
> Maybe it's just a question of habit?
what's wrong with habit? there are benefits to habit - the better you
know something, the less likely you are to make a mistake with it.
it's also a question of documentation. Bind's format is well
documented, with numerous books and HOWTOs published over the years.
this documentation makes it easier to train new staff.
while there's nothing "special"(*) about bind's zonefile format, there's
also nothing wrong with it. there was no need to throw it out and
re-invent it....especially when the re-invention is no easier to
manipulate with scripts and is much harder for a human to read.
(*) actually, the "special" thing about it is that it has existed for
years, it is the de-facto standard, and that there are thousands of bind
servers out there which use the format. these things are important,
whether djb thinks they are or not.
> > nobody with more than a handful of domains is going to throw everything
> > away and convert to a new nameserver program that they know nothing
> > about...and haven't been able to test adequately because it can't
> > (won't!) read their hundreds or thousands of existing zone files.
>
> You can use zone transfers to convert the bind data to djbdns format. Eg:
>
> tcpclient dns1.panic.mil 53 axfr-get panic.mil zone-panic zone-panic.tmp
>
> This can be easily automated for thousands of zones.
>
> > i'd love him to do this. i've been wanting a replacement for bind for
> > years.
>
> It's there already! You just have to adopt a more flexible stance. Ideas
> evolve, new ways of solving problems arrive.
no, it is NOT there already! i don't want to convert hundreds of
zonefiles, i want to use my existing ones. i've already got tools and
procedures in place for managing DNS updates, i have no intention of
throwing everything away and starting from scratch.
djb never wants to understand this point, but this is crucially
important. existing procedures and tools have value.
this is exactly the same problem as with qmail - if you want to switch
from, say, sendmail to qmail, you have to throw away the entire
configuration of your mail server and start again from scratch. that is
why qmail failed as a viable replacement for sendmail, and that is why
djbdns is failing as a replacment for bind. (postfix succeeded where
qmail failed because it provided a migration path).
> > unfortunately, it's the qmail problem all over again - djb sees no
> > benefit at all in backwards compatibility so, IMO, djbdns is doomed
> > to the same role as qmail - a good example showing the way forward
> > but ultimately destined to be superceded by another program which
> > learns from its successes (and mistakes!) and also provides
> > backwards-compatibility.
>
> I question the need for obligatory sendmail backward compatibility, as
> long as RFCs are respected. You are not forced to change, after all.
precisely my point. i wasn't forced to change, so i didn't - i waited
until a program (vmailer aka postfix) came along that provided all the
benefits (and more) of qmail, that also had backwards compatibility with
my old sendmail stuff.
i experimented with qmail for over a year before postfix came along, and
i even installed it on several mail servers (new systems on small
internet gateway boxes that had no legacy config to worry about), but i
had no intention of changing my existing mail servers to qmail - i
couldn't afford the downtime and i couldn't afford the risk of disaster.
when postfix came out, though, i switched them all (including the qmail
boxes) over to postfix within 6 months....and i was able to do this
because postfix provided a migration path that allowed me to do a staged
transition with backwards compatibility and minimal downtime AND (most
importantly!) the ability to easily revert back to sendmail if anything
went wrong. first i installed postfix as a (faster, more secure) bare
replacment for sendmail, without using any of it's extra features...when
that proved successful, i was able to start using more and more of
postfix's features.
i intend to do exactly the same with dns, i'll wait until there's a
decent replacement for bind that has native support for my existing
zonefiles. if dbjdns implements that, then djbdns may well be that
program. if not, then i'll have to wait longer for a replacement.
the point here is that evolutionary change via a staged migration path
is far safer and far more likely to succeed than revolutionary change
that requires throwing out the old and starting from scratch.
> > the successor program will also be free software, with a real free
> > software license rather than djb's non-free license.
>
> You have a point about the license. I understand DJB's worry, though: change
> the license and suddenly there will be n incompatible versions of the same
> software. It would be nice to have a Unix Standard Base ;-)
the many thousands of free software packages which don't have that
problem would seem to prove him wrong.
> You can find the reasoning at
>
> http://cr.yp.to/compatibility.html
(actually, that's his reasoning for his weird configuration style, not
for his license. his reasoning for his license quirks is even more
specious)
yes, i've read it. i think he's wrong. he claims that it's more
important for the configuration and directory structure of programs to
be 100% identical from one system to another than it is for programs on
the same system to conform to the same policy. he's obviously not a
systems integrator. most people couldn't care less about the
configuration details of systems that they don't even use - they just
want all the software on *their* system to operate in a consistent
manner.
> > it would also help in testing and/or migrating to djb's software if he
> > tossed out his bizarre systems administration ideas and used plain-text
> > config files like everyone/everything else rather than magic filenames
> > inside a hard-coded directory tree to configure things. IMO, he's a
> > good programmer but a lousy systems admin.
>
> But he uses plain text config files. And at some point, you'll need a hard
> coded path.
he also uses magic filenames within directories, and he uses them
extensively.
> > he should toss out the crappy ucspi-tcp and daemontools too - he may
> > like them, but they're basically just a needless reinvention of
> > inetd & tcpwrappers that provide no advantages but are significantly
> > uglier to configure and use.
>
> You're letting old habits get the better of you.
no, i just don't like djb's needless re-inventions of the wheel and i'm
not particularly keen on change merely for the sake of change. i've
changed the software i use many times over the years, but only when the
benefits of changing significantly outweigh the disadvantages. there
aren't any significant benefits of daemontools or ucspi-tcp over inetd
and tcpwrappers.
> inetd, xinetd and syslog are known for having security, performance and
> reliability problems.
>
> He designed better tools and factored out common code. IMHO, the /service
> scheme and supervised daemons are a better solution than the init.d
> scripts.
>
> Once you are accustomed to it, you won't want to go back to the
> traditional way of doing things.
i did get used to it. i know how it works and i know how to configure
it, but i still loathe it and i will use anything else in preference to
it. e.g. i got rid of bind and ran djbdns for several months as a
caching-only server on my home gateway box...i switched to maradns
shortly after discovering its existence (after testing that it worked).
i also ran djbdns for months on several web servers and mail servers to
speed up resolving IP addresses in log files and to speed up RBL checks
etc - i switched them to maradns too.
both maradns and dbdns make reasonable caching-only servers. for me,
maradns wins because of it's license and it's lack of djb weirdness.
maradns isn't particularly good software, but a) it's GPL, b) it doesn't
have djb's weird configuration style and c) it's adequate for the task i
want to use it for. i still won't use it as an authoritative server
because it isn't backwards compatible with bind zonefiles and its CSV1
zonefile format sucks.
> > it's as if he reinvents stuff that works perfectly well just to make
> > people conform to his strange ideas about how systems should be
> > configured - throw everything out and implement DJB's One True the.
>
> Only the original programs he reinvented don't work perfectly well.
> Far, far from it.
>
> We're talking about sendmail, bind, inetd, syslog, etc.
aside from bind, there are replacements for all of those programs which
solve their problems while still providing backwards compatibility.
hopefully, bind will have a backwards compatible replacement too one
day.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: