rndc and Updated Zones in bind-9.1.0

[Martin McCormick]

	Thank you very much.  You have saved me/us a lot of
wasted time.  

Mark.Andrews at nominum.com writes:
>
>	BIND 9.1.0 has a bug in that it treats a zone declaration
>	with "allow-update { none; };" as if it was a dynamic zone.

	That is exactly what was happening.

>	This is fixed in 9.1.1rc1.

	I got bind-9.1.1rc3.

>	If the zone is not dynamic then you can edit the zone file.

	I see that, also.  When I had

	allow-update { 127.0.0.1; };

the zone file would get hashed every time I did a reload which
makes sense if named "thinks" that it is dynamic for that zone
and does not expect one to manually edit the file.  As soon as I
changed the localhost or 127.0.0.1 designation to

	allow-update { none; };

bind did not touch the zone file after a reload and a test record
added to the file showed up in the next zone transfer.

	At least, I did successfully get nsupdate working during
the confusion and it is going to be very handy when we start
running dynamic zones.

	Now, those of you switching to bind-9 might want to file
this next bit of information in your survival kit.

	If you have a stealth master, in other words, your
official master is really a slave to a server that is not listed
as your master, be absolutely sure where your nsupdate directives
are going.  I had installed a key in the named.conf file on the
stealth server and referred to that key in the nsupdate command as in

nsupdate  -kKxxx.private /home/dir/file

	It kept complaining about the key not working.  Using the
debug flag showed that lacking a designated server, nsupdate
figured out that I must want to talk to the master for the
domain.  That particular server is running bind-8 and knows
nothing about keys yet.  Of course it was failing.  Everything
worked properly as soon as I put the server directive in the
batch file that contained the update.  

	Again, thanks for telling me about the bug in 9.1.0.  I
did not know enough, yet, to be sure that there was a real
problem or that I was simply not using the new named properly.

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