[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DNS servers


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...


Reply to: