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 <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
