Re: DNS servers
On Wed, 20 Nov 2002 16:51, 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.
Is that any easier or more difficult than doing an equivalent operation for
the standard format?
Having an entire zone file generated by M4 with a Makefile is not so
difficult...
> Besides, I don't think bind's file format has anything special per se.
> Maybe it's just a question of habit?
Yes, habit multiplied by hundreds (or thousands) of domains becomes difficult
to break!
> > 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.
True. But "cp" is easier...
> > 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.
DJB is good at devising new ways of solving problems. But it would be handy
if he restricted his new ways to the things that actually need it rather than
replacing things unnecessarily.
Also having a replacement as an option with the alternative of using the
traditional method is good.
Postfix does virtual domains in a different fashion to sendmail and allows you
to use both the Sendmail method and the Postfix method in the same server.
/etc/aliases is getting rather old but it works OK and it's good to have a
mail server that supports it.
Qmail does everything different and DJB doesn't accept patches to rectify
this. I went from Sendmail to Qmail to Postfix. Sendmail to Qmail only gave
me Maildir as a new feature, later on when all software supported Maildir I
was glad to quit using Qmail.
> 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
That's nice for him. I'll stick to software that meets the DFSG and which has
the features I need.
I am not going to try and convince people not to use DJB's software. Qmail is
a good program. If all Sendmail users would switch to Qmail then the net
would operate much better. I just think that Postfix is better overall.
> > 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 ;-)
There is not incompatable version of Postfix...
> As is, the license is ok for end users but not for distros.
Apart from users who want to stick with distro packages.
As a mail server USER the Qmail license is bad for me. I am better able to
build my own packages of Qmail than 99% of all Debian users, but I would
still prefer to stick to software that is packaged.
> > 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.
It's something that sounds good when you first think about it. But then
becomes painful later. Think about having an instance of the software
installed in a different location without using chroot()...
> inetd, xinetd and syslog are known for having security, performance and
> reliability problems.
rlinetd is fine AFAIK. What is the problem with the regular inetd? xinetd is
known for having problems, but there are plenty of other inetd type programs
to choose from.
What security problems does syslogd have? It's performance generally isn't a
problem if you use the "-" option on some of the busy log files.
> 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.
Been there, done that, ran screaming back to inetd. ;)
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: