bind 8.2.4: limiting used memory?

Thu Aug 9 22:03:06 UTC 2001

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

On Aug 9 2001 18:21 -0000, D. J. Bernstein wrote:

> Michael Kjorling writes:
> > what do you mean with ``upgraded domains''?
>
> Domains for which the DNS server software is upgraded.
>
> It would be foolish to count a BIND 4.9.6 server against djbdns. People
> didn't have djbdns as an option when they installed BIND 4.9.6.

But perhaps not as foolish to count new installations of BIND 8.2.3+
or 9.1.x (or even the 9.2 betas) against djbdns?

Also, stay clear of the terminology. You are mixing up the word
`domain' with `name server'.

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

> > Well, _sorry_, but I did read the instructions. I did follow them. I
> > did run `config'.
>
> No, you didn't follow the instructions.
>
> qmail's INSTALL tells you to read INSTALL.ctl. INSTALL.ctl tells you to
> run config-fast your.full.host.name ``so that qmail will accept mail for
> your.full.host.name''---which is what you wanted. You didn't do that.

If you would have cared looking at the envelope header of my posts
before trying to jump at me, you would have noticed one very
interesting fact. My IP as of current is 213.88.238.204. If you
perform a reverse lookup on that one in the DNS, you get (dig output
snipped for clarity):

	; <<>> DiG 9.2.0b2 <<>> -x 213.88.238.204
	;; ANSWER SECTION:
	204.238.88.213.in-addr.arpa. 86400 IN   CNAME   204.192-28.238.88.213.in-addr.arpa.
	204.192-28.238.88.213.in-addr.arpa. 86400 IN PTR varg.mcpoolen.se.

That is, my host's name is *not* kjorling.com (as you want to belive,
and wants to make other people belive), but rather varg.mcpoolen.se.
But how often do you think I am using the real FQDN for email? Very
rarely. In the same way as I don't think you are using the email
address djb at a.mx.cr.yp.to very often. WHY? It is much more complicated
to remember. People might argue that the spelling of my domain name is
tricky - but it is my last name, spare the umlauts.
firstname at lastname.com is a fairly simple scheme to remember, so
anyone who knows how to spell my name will automatically have my email
address. They won't have to use michael at varg.mcpoolen.se (even though
that is possible). In fact, I don't know of anyone who does. But of
course:

	; <<>> DiG 9.2.0b2 <<>> kjorling.com mx
	;; ANSWER SECTION:
	kjorling.com.           86400   IN      MX      10 ulv.mcpoolen.se.
	kjorling.com.           86400   IN      MX      5 varg.mcpoolen.se.

You can perform these lookups yourself if you do not belive me, or are
missing some absolutely crucial records.

> INSTALL.ctl later mentions config as an alternative ``which looks up
> your host name in DNS'' and ``looks up your local IP addresses in DNS to
> decide which hosts to accept mail for''---which isn't what you wanted.
> The problem, of course, is that you never read INSTALL.ctl; you simply
> ran the config script.

Would you mind stop jumping at other people, for a change? If you
would have read what I spent time keying in on the computer, I *did*
read and follow the instructions. Whether splitting up the
installation instructions is a good idea or not is NOT a point I am
going to argue here - nor anywhere else for that matter. (Even though
I personally prefer a single `INSTALL' file, coupled by a `README' and
similar documents to get one started.)

If I was using the email address michael at varg.mcpoolen.se (which is
perfectly valid on the Internet, varg even has a MX record with a 0
cost pointing at itself), your setup scripts would probably have
worked nicely. BUT I AM NOT using that address.

Is that clear enough?

> I realize, as I said before, that the qmail installation instructions
> take several minutes to read. Quite a bit of my subsequent development
> work has focused on reducing the amount of information that users need
> to absorb before setting up my packages. You can see the results in
> daemontools, for example, and in ucspi-tcp, and in djbdns.

I am getting mighty tired of this. I have work to do. Others here have
work to do. How much more of our time are you going to waste preaching
about the claimed excellence of your own software packages?

I am not an idiot. I happen to prefer software which is in wide use
and support is widely available for, not only from the manufacturer
and their contractors of various forms. I happen to like the
combination of Linux, BIND, Apache, and Sendmail, to serve Internet
content. If others want to use BSD, Windows NT, IIS, Active Directory,
Exchange, qmail, djbdns, whatever - FINE! I have absolutely no
problems with that at all. *As long as they respect my choice of
platform.*

> > /etc/rc.d/init.d/sendmail
>
> http://cr.yp.to/compatibility.html

I looked at this page. I can agree on one point - that having half a
dozen different ways of doing things on half a dozen different
operating systems from half a dozen different vendors might not be a
great thing. But quite often, configuration paths, installation paths
and all kinds of paths (and in some cases even the names of the
executable files) can be changed using simple command line switches to
the now-mostly-standard-software-equipment `configure' script. I think
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.

If the makefile is written that way, and the defaults are sane (they
often are), you should be able to simply say `make'. Most programs
choke on this since they want you to take concious steps to configure
it. But still, `./configure; make; make install' is oftentimes not
hard. It is quicker to type out such a command than to read through
3-4 files to figure out how to install a piece of software properly,
and still end up with an installation that does not work.

> > 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? I looked
but cannot find it.

After all, setting up a new zone is probably more common than setting
up a new slave server. 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.

For example:

> Problem: Avoid destroying a zone if there's trouble saving new data:
> e.g., not enough disk space, or a sudden power outage.
> BIND solution:
> 1. Copy the zone file.
> 2. Edit the copy.
> 3. Sync the copy to disk.
> 4. Rename the copy.
> djbdns solution: Relax. add-host handles this automatically.

You must be using a mighty stupid editor if it doesn't check to make
sure changes are properly sent to the disk cache (for further writing
to the disk). And what do you mean that add-host handles a power
outage automatically? If there is a power loss or the system goes down
without warning for some other reason before the changes gets flushed
from the RAM cache onto the disk, how is the system supposed to know
about those changes?

That aside, you hardly ever need to sync manually. I belive Linux does
that once a minute or more often, and would be surprised if other
UNIXes are not periodically flushing their disk caches.

Get a life.

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

iD8DBQE7cwigKqN7/Ypw4z4RAgtQAJ0anJXHvugYGxi9THtF7/wAj4dYuACeNQjH
bIXxg63wDNVBL78GHM2krTc=
=omxq
-----END PGP SIGNATURE-----