Re: DNS servers
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?
> 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.
> 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.
BTW, qmail is doing well. Take a look at the last DJB smtp server survey:
http://cr.yp.to/surveys/smtpsoftware6.txt
> 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 ;-)
You can find the reasoning at
http://cr.yp.to/compatibility.html
As is, the license is ok for end users but not for distros.
[snip dents]
> 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 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.
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.
> 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.
Regards,
--
Adriano
Reply to: