bind 8.2.4: limiting used memory?

[Michael Kjorling]

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

On Aug 10 2001 18:13 -0000, D. J. Bernstein wrote:

> Michael Kjorling writes:
> > 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,
>
> In fact, djbdns has supported client differentiation since version 0.75
> in January 2000. It offers per-record granularity; this is much easier
> to use than BIND's per-zone granularity.

OK - I can give you a right there. Whether per-record or per-zone
granularity is better, is another of those matters I am not going to
discuss. At least BIND adheres to the RFCs' definition of a zone file.
Note that I am *not* saying that djbdns does not; I am simply pointing
out that the RFCs (AFAIK) provide no means of specifying which
client(s) and/or network(s) should get which response to what queries.


> > And it still takes less than one second to write to disk.
>
> My perspective is different. You see your 38 zones; I see millions of
> zones on thousands of servers. There are a huge number of zone files
> being written to disk every day, and a huge number of power outages
> every day. The two events occasionally coincide.

Which is why power backups that can shut down the systems in a nice
way are so important.


> Reliability means never having to say you're sorry.

I am sorry. To have to take this discussion instead of doing work
which could actually *benefit* others, and myself.


> > And how does it handle a trashed file system due to a power outage?
>
> Obviously there's no hope if the disk hardware can't read the blocks
> that were written. This is why critical servers use RAID. There are also
> disk-recovery services that can handle almost all dead disks.

And there is Uninterrupted Power Supply, UPS. Battery backups that can
at least keep the system up for long enough to bring it down in a
nice, well controlled fashion.

Why do you think so many servers have that?


> If there are no I/O errors, a ``trashed file system'' is an OS bug. Most
> UNIX filesystems are carefully designed to write blocks to disk in the
> proper order. The only big exception is ext2fs.

Would you consider a loss of power to be an "I/O error"? (This is a
honest question!)

If you are having such a problem with ext2fs, there are other file
systems available. Take your pick.

I, for the moment at least, stick to ext2fs because it is well tested
and fairly reliable under the conditions I am seeing. If those would
change dramatically (e.g., power outages become much more common than
they are today or the quality of the disk drives and/or controllers
would significantly drop), I might have to reconsider that decision.


> > There is nothing stopping you from either grabbing scripts off the
> > Internet or developing them in-house to automate the process.
>
> If the BIND company starts supporting those solutions, they can let me
> know, and I'll update my table.

The ISC is no more a "BIND company" than it is a "INN company" or
"DHCPD company".

That set aside, do you support every possible way of doing things in
djbdns in the way you apparently want to see the ISC supporting every
possible way of doing things with BIND?

What if I want to tie a web backend to djbdns, and for some reason
want to directly modify the zone files instead of relying on the
included binaries?


> > I don't think that adding a host to the DNS and adding a zone should
> > be the same thing.
>
> They aren't: add-host adds hosts, and add-ns adds name servers.

And how about adding an entirely new zone?


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

iD8DBQE7dEmWKqN7/Ypw4z4RAsolAJ9YDrZDjMA44kaAoyHMq+nAcjw1LgCeM9+U
fB6HNp3po8tdD0fG6gmKz6g=
=hMT0
-----END PGP SIGNATURE-----