Re: DNS servers
On Wed, Nov 20, 2002 at 07:43:26PM -0000, D. J. Bernstein wrote:
> Craig Sanders writes:
> > nobody with more than a handful of domains is going to throw everything
> > away and convert to a new nameserver program
>
> Five of the top ten domain-hosting companies on the Internet---including
> Namezero, the largest---have switched to djbdns (tinydns) to publish
> their domains.
good for them. i'm not going to blindly follow.
> djbdns can simply transfer the zones from BIND. The upgrade instructions
> explain this in detail:
>
> http://cr.yp.to/djbdns/run-cache-bind-1.html
> http://cr.yp.to/djbdns/run-server-bind.html
i've read these. they document a procedure that i don't want to
perform.
> You say that you want ``native support'' for BIND's configuration
> files and zone files, not just a zone importer.
yes, precisely. a converter isn't good enough.
> Could you please explain what advantage this ``native support'' would
> have?
1. i already have them, and i have scripts and procedures in place to
manage them. i want a better name server, but not at the price of
throwing away my existing stuff.
2. i already know the quirks of bind zonefiles. i see no reason to
learn a new set of quirks when there aren't any benefits in doing so.
3. bind zonefiles are human readable. tinydns-data zonefiles are not.
4. bind zonefiles are well documented in numerous books and HOWTOs.
5. there's no converter from djbdns back to bind zonefiles(*) so
switching to djbdns doesn't leave me the option to back out if anything
goes wrong unless i discover the problem before i start updating zones.
i'm paranoid about software changes, i don't like making ANY radical
change that provides no way to back out.
(*) the output of named-xfer isn't good enough. it loses all
human-readable formatting and comments, and changes the order of
entries.
6. i can't see why it's so difficult to provide native support for bind
zonefiles. your software already converts xfer-ed zones on the fly, why
can't it read named.conf (or just a list of zonefiles) and import the
listed bind zonefiles from local disk into the .cdb database?
if i was to switch to djbdns, this is the way i'd do it. i'd retain my
bind zonefiles and use a Makefile and a script to create data.cdb
> If the BIND file formats are so wonderful, why does the BIND company
> keep changing them?
i have no idea why they change them. i'm not happy about that, either.
i didn't change to bind9 while it rejected my perfectly valid bind8 zone
files either....and when i did change to bind9, i changed back almost
immediately when bind9 turned out to have enormous memory leaks.
i'm under no illusion that bind (4 or 8 or 9) is good software. it's
not. i'd change in an instant if there was a good backwards-compatible
replacement for bind. the trouble is that there is no good replacement
for it yet, djbdns included.
djbdns has some nice features/ideas - i particularly like the use of
rsync to transfer zones (i wrote my own named-xfer wrapper script to
allow the use of rsync some time ago) - but those features don't
outweigh the disadvantages of incompatibility.
> I have a comparison table at
>
> http://cr.yp.to/djbdns/blurb/easeofuse.html
>
> showing that all sorts of operations are easier with djbdns than with
> BIND. Have you actually tried using the djbdns configuration
> mechanism? What specific operations did you find easier with BIND?
i've seen it before. IMO, it's self-serving propaganda peppered with
prejudicial language that attempts to make trivial operations seem
difficult or prone to error - e.g. almost every bind solution ends with
"Look for errors in your system's logs." but not one of the djbdns
solutions does the same, implying that mistakes and faults are
impossible with djbdns.
i really don't care whether you think something is easier or not. i'm
not at all willing to throw away my existing configurations, procedures,
and scripts just on your word. i've been deceived by your bizarre
configuration ideas before - they may make sense to you, but i find them
to be an extremely ugly and clumsy way of configuring things, and they
result in an unmaintainable mess.
yes, i have tried djbdns configuration. i ran djbdns on several
machines for several months as a trial and learning-exercise. i don't
like it. i find the configuration to be awkward and clumsy and ugly.
that's a common failing with all of your programs.
> > plain-text config files like everyone/everything else rather than
> > magic filenames inside a hard-coded directory tree
>
> 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.
> The obvious point is that djbdns makes the configuration change easier
> for people than BIND does.
in your opinion. i prefer editing a config file. i don't want the mere
existence of a file in a directory to be magic. i want the ability to
leave old rules commented out in a config file - this makes it easy to
trial something because i can quickly revert if it doesn't work. i want
to be able to manage changes with RCS. i also want the ability to leave
notes (to myself and to my assistant sysadmins) in the configuration
file so i can document WHY i did something and/or leave instructions
saying "DO THIS" or "DO *NOT* DO THIS".
also, i don't want any new directories (such as "/service") in my root
directory. i don't even want a symlink to /var/services or whatever.
i'm quite happy with the existing directory structure and i expect
programs to conform to that rather than make up their own rules.
> The more subtle, and more important, point is that djbdns makes the
> configuration change much easier for _programs_ than BIND does. If
> someone wants to write a tool providing another configuration UI,
> he'll have a much easier time with djbdns than with BIND, because the
> file formats are much simpler. Everyone benefits.
it doesn't make it any easier for programs either.
i've had no problems writing scripts to maintain either zonefiles or
named.conf. e.g. i've got scripts which scan the daemon.log file for
entries that say a primary is no longer authoritative for a domain and
automatically remove these stale secondary entries from our config -
this is necessary because it's my experience that primaries almost never
bother to inform secondaries when their customers move to another DNS
host.
as ever, you're only willing to see things YOUR way and refuse to
concede that other viewpoints have any validity.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: