Hi, On Thu, Nov 21, 2002 at 11:54:21AM +1100, Craig Sanders wrote: > 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.
sorry, but this is getting stupid. You're going to blindly stay where you are. > i've read these. they document a procedure that i don't want to > perform. Must be a real challenge... > 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. You can keep these as a backup. > 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. There are no quirks. > 3. bind zonefiles are human readable. tinydns-data zonefiles are not. Wrong. Takes 15 minutes to learn. > 4. bind zonefiles are well documented in numerous books and HOWTOs. The tinydns-data format can, and is, exhaustively documented on some three sheets of paper. It's apparently easier to wade through a pile of books and paper instead of learning these three pages, oh my. > 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. Wrong again. You convert your BIND zone files to tinydns-data format by doing a zone transfer from a live BIND server. You can convert your modified zone data back the same way - having a BIND server doing AXFRs from a tinydns/axfrdns combo (which you'd set up anyway). Takes similar amounts of time. > (*) the output of named-xfer isn't good enough. it loses all > human-readable formatting and comments, and changes the order of > entries. These should be kept elsewhere anyway, and you can also place comments in a tinydns-data file. If you followed the advice to place the data for each domain in their individual files, you've got little to worry about... eg I manage my data working from a set of files like "domain1.com", "domain2.com"... and so on. Really black magic rocket science, that is. > 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? What about using your genius and wisdom to develop a patch that retrofits this ability to djbdns and post it to www.lifewithdjbdns.org, instead of whining all day that Dan won't waste his time on such waste? This site serves a "how-to" style document on how/what to do when moving to djbdns. > "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. They are much harder to make - see my other message on how using djbdns can help debugging BIND zone files. > not at all willing to throw away my existing configurations, procedures, > and scripts just on your word. As stated numerous times by now, do it in a lab - you shouldnt' go live with anything immediately anyway. > to be an extremely ugly and clumsy way of configuring things, and they > result in an unmaintainable mess. Wrong. Only right for you. > 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 You can remove the offending magic file immediately if you don't like it. 'rm' is your friend... > to be able to manage changes with RCS. i also want the ability to leave Perhaps you might want to switch to CVS, or is this also an incompatible evil way of doing things? (No, I don't hear "Subversion" in the background for the sake of this discussion). > 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". (a) you can, and (b) you should document elsewhere, too. > 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. So you'll never upgrade. When did Linux start to include /boot as a standard directory? Most other systems still don't have it. Must also be something evil... Last, --Toni++
