bind 8.2.4: limiting used memory?

[Michael Kjorling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 10 2001 00:08 -0000, D. J. Bernstein wrote:

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

And how does it handle a trashed file system due to a power outage?
That is a very real threat in many UNIX environments where you don't
have some kind of power backup, and I have managed to lose some 5 GB
of data myself that way. (Since the system was newly installed, I
didn't have any current tape backup either.) And it wasn't even due to
a power outage. The system froze so badly that I had to hit the Reset
button.

How big does a zone file need to be in order for your "problem" to be
a problem? Let's say the usual hard disk can sustain a write rate at 5
MBytes/second (this is completely unscientific). Given a reasonable RR
average size of 30-40 bytes (this should cover most of them), we can
write approximately 125.000 resource records (or more) per second. How
big is the average zone file on the Internet, and what can be counted
as a still reasonable extreme (that is, not the TLD zones)? I don't
know, but a hundred thousand RRs in one single file seems quite a bit
to me. And it still takes less than one second to write to disk.

And how many DNS admins are actually stupid enough not to check their
disks every now and then? It's as easy as:

	[root at varg /root]# df -h /var/named
	Filesystem            Size  Used Avail Use% Mounted on
	/dev/hda6             1.4G   69M  1.3G   5% /var
	[root at varg /root]#

Most UNIXes (including Linux, AFAIK) use write-through disk caches. I
do not know the exact implementation details (most are closed-source,
and the Linux kernel source code is quite big) but I suspect it would
be a simple matter that instead of checking the free disk space when
you actually write to the _disk_, you check and reserve enough disk
space when you write to the _cache_.


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

There is nothing stopping you from either grabbing scripts off the
Internet or developing them in-house to automate the process. I have a
fairly simple `newdomain' Bourne shell script on my systems which
takes care of setting up DNS, e-mail and a web site, including
appropriate symlinks and aliases. Since it is proprietary though, I
cannot share it with the group. I will see what can be done about
that.

I am sure there are other, equivalent scripts available on the
Internet.


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

In what way do you consider it to be stupid? A power outage *is* a
real threat and has the potential of trashing the file systems which
did not have time to unmount properly. I have experienced this myself,
as I said.

I don't think that adding a host to the DNS and adding a zone should
be the same thing. Plus, you don't absolutely need either a
"localdomain" (or similar) forward zone or a 0.0.127.in-addr.arpa
reverse zone. If your system is configured properly, it will revert
back to /etc/hosts or its equivalent, where these should be defined
anyway.

And you can quite easily have a "template" zone file, which you just
copy and then tailor to your specific needs by adding the records not
in there already. For most ISPs, for example, this does not translate
to many records. If done in a simple script, you can do it quickly:

	#!/bin/bash
	if [ "$1" = "" ]; then
		echo "Domain name must be specified: $0 domain host"
		exit 1
	fi
	if [ "$2" = "" ]; then
		echo "Server name must be specified: $0 domain host"
		exit 2
	fi
	if [ -f /var/named/zones/masters/named.$1 ]; then
		echo "Zone file /var/named/zones/masters/named.$1 found, aborted"
		exit 3
	fi
	cp -f /var/named/zones/Template /var/named/zones/masters/named.$1 && \
	echo "zone \"$1\" in { type master\; file \"zones/masters/named.$1\"\; }\;" >> /var/named/named.conf && \
	rndc reload || \
	echo "Zone installation failed!"

I haven't tested this particular script, but you get the idea. Of
course, if you are using BIND 9's views, it gets more complicated; but
as far as I have understood that isn't a feature djbdns offers, so we
don't have to dwell into that.


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

Aside from the fact that my "workstation" actually does serve domains.
Not a great deal of them - I am no ISP - but the keyword "zone"
appears at the first column in my named.conf 38 times according to
grep. I know that I have three stealth slaves and five local zones,
which leaves 30 zones being served to the Internet. And that number
keeps increasing.


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

No, I ran config. And how was I supposed to accept mail for the other
29 domains? (Of which I should receive mail myself for some 20.)


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

Not only on that, but getting qmail to work. Read what I write instead
of making things up yourself.


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

Do you know what you are? An asshole.

As someone else (who shall remain nameless unless that person decides
to step out) said - if this is your customer support methodology, I
(too) have seen enough of it.

If you would, instead of trying to jump at other people, spend the
time at either helping those who are using your software or develop it
further, this would be a much better world.


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

Excuse me? This sounds rather contrary to me. You say that normal
users (which apparently are the ones who are using your software)
don't want to set parameters, but at the same time you say that it is
possible in a nonstandard way?


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

(The obvious advantage of `configure' is that it CREATES the makefiles
after checking to make sure that your build environment is OK and can
actually support the compilation you request. Which, in case you make
a mistake (e.g., misspelling a path) can save a whole lot of time if
the program is big.)


Michael Kjörling

- -- 
Michael Kjörling - michael at kjorling.com - PGP: 8A70E33E
Manager Wolf.COM -- Programmer -- Network Administrator
"We must be the change we wish to see" (Mahatma Gandhi)

^..^     Support the wolves in Norway -- go to     ^..^
 \/   http://home.no.net/ulvelist/protest_int.htm   \/

***** Please only send me emails which concern me *****


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7c90LKqN7/Ypw4z4RAuHMAKCT8HLRUZoNZMrIMcg0T5MWBRpTOwCfXw/f
JdWCN3y/0XfAMfxNgg+fcJg=
=WoGA
-----END PGP SIGNATURE-----