bind 8.2.4: limiting used memory?

[D. J. Bernstein]

Michael Kjorling writes:
> You must be using a mighty stupid editor if it doesn't check to make
> sure changes are properly sent to the disk cache

Use vi on a large zone file. Make a change. Start saving the file. While
vi is writing the file, pull the plug.

When your machine reboots, you'll have a truncated zone file. Disaster!
Try it out if you don't believe me.

The easiest BIND solution, as I said, is to edit a copy of the zone
file, sync the copy to disk, and then rename the copy. Sure, it's only a
few extra commands, but djbdns does it all automatically.

> > > you will find that setting up a zone with BIND is extremely easy
> > http://cr.yp.to/djbdns/blurb/easeofuse.html
> And exactly where does it mention how to set up a new zone?

That's part of the ``Set up a server on 1.2.3.5 to publish information
about x.mil and 1.2.3.*'' section.

As you can see, BIND needs a zone file with an SOA record and an NS
record, as well as a new entry in named.conf, while djbdns does it all
with a simple one-line add-ns command.

> And in the end, that comparisation chart looks
> much like Microsoft's (and other big companies') ones: show the worst
> possible way of doing things in the competitor's software.

Kevin made the same accusation. When I demanded details, he repeatedly
made a fool of himself, just as you've done with your stupid response to
the power-outage section of my web page.

The reality is that I went to a great deal of effort to review all the
mechanisms supported by the BIND company and select the ones that were
easiest to use. If the BIND company starts supporting something easier,
they can let me know, and I'll update my table. In some cases they don't
support _any_ solution, so I explained the easiest solution I knew.

> One name server can easily serve hundreds, thousands or even tens of
> thousands of domains (called zones in a DNS context).

Right. I'm weighting servers by the number of second-level domains that
they serve. This means that DirectNIC's heavily used servers are counted
multiple times, while your workstation's cache isn't counted at all.

(Surveying caches is difficult. My cache doesn't respond to queries from
unauthorized machines.)

> I *did* read and follow the instructions

Nope. INSTALL.ctl says quite clearly what to do, which in your case is
config-fast kjorling.com. That isn't what you did.

Configuring qmail to accept mail for additional host names is covered in
FAQ 3.1, which the installation instructions also told you to read. Put
the names into control/locals and control/rcpthosts, and give a HUP to
qmail-send. The idea that you spent several hours on this is absurd.

I fully understand that some people aren't willing to spend the several
minutes that it takes to read the qmail installation instructions. This
is, as I said, something that I've put a lot of effort into in my newer
packages, such as djbdns.

> qmail was the first program I ran across since I switched to Linux
> (and I have compiled many) that did not have a pre-compilation
> `configure' script allowing me to set various parameters.

Normal users don't _want_ to set parameters; they want the software to
just work. Anyway, qmail's compile-time parameters are set in conf-*
files, as INSTALL explains right at the top.

(The obvious advantage of conf-* files is that ``make'' understands
dependencies upon them, while it doesn't understand dependencies upon
the ``configure'' command line.)

---Dan