Re: DNS servers
On Thu, Nov 21, 2002 at 05:12:20AM -0000, D. J. Bernstein wrote:
> Craig Sanders writes:
> [ http://cr.yp.to/djbdns/blurb/easeofuse.html ]
> > almost every bind solution ends with "Look for errors in your system's
> > logs." but not one of the djbdns solutions does the same
>
> What you fail to realize is that djbdns puts the errors on your screen,
> in response to the command you just typed, right before the next prompt.
> That's why the extra step of looking at logs is unnecessary for djbdns.
and bind doesn't alert the operator about config errors? yeah, right.
what you fail to realise is that some of us have used both bind and
djbdns and are aware of the pros and cons of both and <gasp!> have
decided that the benefits of changing to djbdns do not outweigh the
disadvantages.
i'd really like it to be otherwise, because i'd really like to be able
to dump bind. the trouble is that there isn't a viable replacement for
bind yet, so i won't be able to do that for some time.
> [ zone files ]
> > i have scripts and procedures in place to manage them.
>
> Ah. Did it ever occur to you to mention this site-specific issue before
> you made broad comments about the usability of djbdns?
a) i did point that out before you jumped in
b) it isn't a site-specific issue. lack of bind zonefile compatibility
is a general problem with djbdns (and all other alternative nameservers
except for NSD at the moment).
> Did it ever occur to you to ask for scripts that do the same thing
> with djbdns? What do your scripts actually do?
i don't want to do the same thing with tinydns-data files. i consider
that file format to be ugly, difficult to read and a PITA to work with.
i want to keep on using my existing zone files with my existing scripts
and change-management procedures.
> > i can't see why it's so difficult to provide native support for
> > bind zonefiles.
>
> Because those files are in an unstable, horribly complicated format.
> Crude parsing is easy, but reliable parsing is extremely difficult.
you manage to parse them when djbdns secondaries a zone from a bind
server, why is it suddenly impossible to do the same when they come from
the local disk?
> > 3. bind zonefiles are human readable. tinydns-data zonefiles are not.
>
> Let's try a simple example. I find
>
> =bear.heaven.af.mil:1.2.3.6
> @heaven.af.mil:1.2.3.4
>
> much easier to read than
>
> bear.heaven.af.mil. 86400 IN A 1.2.3.6
> 6.3.2.1.in-addr.arpa. 86400 IN PTR bear.heaven.af.mil
> heaven.af.mil. 86400 IN MX mx.heaven.af.mil
> mx.heaven.af.mil. 86400 IN A 1.2.3.4
>
> and much less error-prone. Don't you?
no, i don't. i find the latter much easier to read and less prone to
making errors when editing it. white-space makes things easier to read
for humans.
but that was part of my point - you assume that your way is so much
better than any other way that you refuse to see alternate
viewpoints....if you were right that would be tolerable, but in
inherently subjective matters like this one you're not right.
what is right on my system is what makes sense to me, not what makes
sense to you.
> > > Let's try a concrete example. With djbdns, to authorize clients with
> > > IP address 10.*, you touch /service/dnscache/root/ip/10. With BIND,
> > > you edit named.conf and add something to the allow-query line.
> > yes. a good example of something that you believe is easier but isn't.
>
> You ask how to add notes: vi ip/10. You ask how to comment out entries:
> mkdir ipbak; mv ip/10 ipbak. And so on.
not good enough. i don't want dozens of little files, one for each
configuration element. i don't want to have to repeat the same
instructions/comments in each file. i want one file or a small number
of files, preferably with lots of comments embedded to act as
on-the-spot documentation visible right there in vi.
and what guarantee do i have that you won't make "ipbak" a magic
filename in some future release of your software? what guarantee do i
have that you won't make "00-README.NOW" or any other arbitrary
filename/dirname magic?
btw, it's common practice for me to copy a config file before editing
it. usually i copy it to filename.YYYY.MM.DD. using your example, "10"
would be copied to "10.2002.11.20", which looks like a mistyped IP
address. djbdns may be smart enough to cope with that, or it may not -
i don't really care, i don't want to have to worry about crap like that.
magic filenames are a dangerously broken way of configuring things.
> You assert that the djbdns configuration isn't ``any easier'' for
> programs to parse than the BIND configuration. That's ludicrous.
no, it's not ludicrous. it's fact. you may find your format easier,
but (once again) that is an inherently subjective issue.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: