Re: DNS servers
Hello,
On Wed, Nov 20, 2002 at 02:55:08PM +1100, Craig Sanders wrote:
> 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've said it already in private, and I feel compelled to repeat it in
public:
- Encoding the internal representation of DNS data in a standard, if
this really has been done, is a big design error for me.
DNS servers are supposed to talk to each other over the network,
not the file system.
- Wanting support for "native" BIND zone files is like wanting
sendmail.cf for Exim/Postfix/You-Name-It.
The BIND zone file format has proven to be very hard to handle for
both machines and humans alike. FWIW, once I helped a DNS newbie
get on track with his installation. He needed to serve some 50
domains and was working along the famous "DNS and BIND" book that
I also learned my DNS from ;-)
Well, in under half an hour, and using the tools and representations
in djbdns, I was able to point out several dozen errors in his setup
that were not obvious by just reading the zone files.
> 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.
Sorry, but that's just plain wrong. For starters, just use a test
server that's not currently in production to test *any* new software
and fiddle with it until you know what you're doing - this doesn't
apply to DNS only, but to every other software as well. Call it a
'lab'.
On the djbdns mailing list, I see some large hosters with > 100000
domains switching over to djbdns and throwing away BIND. If that's
not large, I don't know what is. There are other alternatives to
BIND - my favourite is probably ldapdns before checking out Fefe's
server - that are even faster and probably even less troublesome
than is tinydns. Unfortunately, I'm still missing a good GPL'ed
resolver :-(
> unfortunately, it's the qmail problem all over again - djb sees no
> benefit at all in backwards compatibility so, IMO, djbdns is doomed to
You already do have a BIND installation, no?
So take a minute and copy the BIND files by zone transfer into native
djbdns format. You can do it in a 5-10 line script, and I've done it
with my zones, arriving at a set of files that contain the data for
one zone only per file. Then you can experiment with it easily
(just cat' them together after some marginal massaging), and start
to play with it.
> the successor program will also be free software, with a real free
> software license rather than djb's non-free license.
This is by far the biggest problem with any kind of DJB software
I have (unless he specifically placed it in the public domain
which he sometimes does).
> 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.
That's also untrue. He doesn't cater for bad old habit, but tries
to find a technical clean solution. It requires some effort to
understand, however, but saves both a programmer and an admin a
lot of work. Ie, a typical client-side qmail installation is imho
maintenance-free whereas today I needed to discover a Postfix
installation that went to store a large number of messages in
a directory that won't ever be delivered for no apparent reason.
> 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
They are the needed re-inventions of inetd and tcpwrappers that are
offering things like load control and a much more fine-grained
access control. It's also much easier to control an application
with daemontools etc. than it is with inetd. Instead of trying to
find a pid which may be a flaky and expensive effort, you can
control the program using a directory path of your choosing and
also easily have several different installations of the same program
if you need them (ok, qmail would require a recompile for different
queue paths etc).
> configure and use. it's as if he reinvents stuff that works perfectly
> well just to make people conform to his strange ideas about how systems
Well, inetd is known to crap out under high loads and also was
at times a security risk. What do you classify as "works perfectly
well"?
Also, did you ever take into account that the software design and
programming style he uses is one important factor to achieve the
security he boasts? Instead of having huge programs that need half
their code just for parsing stupid config files, DJB has made an
effort to put the Unix toolbox approach to work, combining lots
of small programs to achieve a larger task. And he has tried to
follow the KISS principle.
> should be configured - throw everything out and implement DJB's One True
> Way.
No, there is not One True Way, but he has made a lot of progress in
the direction of modern system's administration, imho.
Best,
--Toni++
Reply to: