rndc and Updated Zones in bind-9.1.0

[Martin McCormick]

	After a night's sleep and more study, I am not sure I was
clear about the problem.  Right now, we are not using dynamic
updates.  All the zone information is contained in a file which
is the same old standby ASCII text file starting with the SOA
record and going through all the various types of records one
has.  named-checkzone is perfectly happy with it and bind sends
it out properly.  I was under the impression that this was the
kind of information that got re-read when one did a rndc reload
command.  Our zone had been relatively stable for a few days and
I had unwittingly kept it up to date by stopping and restarting
the daemon on our stealth primary.  After someone reported not
being able to find something that should have been in the zone, I
checked the serial numbers and sure enough, I was sending out a
zone that was several revisions behind.  The only way I could
make it current was to completely kill and restart bind.

	I certainly want to keep the zone current in the proper
way, however, because we will soon be using dynamic dns on some
mid-level domains in our zone.  We will have a mixture of static
and dynamic information for years to come.  Right now, what I am
trying to update is what one could call the traditional
directory/hosts file which has been the data base for domain name
servers for almost 20 years.

	This is definitely not a gripe or complaint.  I am a bit
confused as to how best to emulate the traditional function while
not getting in to any bad habits that will bite us as we make
some mid-level domains dynamic.

	If I need to separate all our A, MX, etc records and use
nsupdate to add and remove them, I can do that.  Is that the new
way to modify the zone?  It makes sense.  I just didn't think of
it that way until now.  I wrote a huge C program over the last
few years that manages our IP number space and it generates the
flat file we use for our okstate.hosts file.  I can certainly
change the way things are done.  I just want to do it right and
once, if lucky.

Martin McCormick WB5AGZ  Stillwater, OK 
OSU Center for Computing and Information Services Data Communications Group