I've started using the new catalog-zones feature, and whilst it has
been pretty nice on one new server, it has been painful to implement
on an existing one.
I run three nameservers for a small F/OSS project, slackbuilds.org.
One of these is a physical server machine, and the other two are
virtual machines. Formerly I had most master zones on one of the
VMs, with mostly slaves on the real machine. An old server is being
removed and replaced with a second VM at a different site.
To make the story easier to follow I'll use these names to refer to
the servers in question:
1. "Master", the physical machine, BIND 9.10
2. "VM1"[1] the existing VM, former master of most zones
3. "VM2"[2] the new virtual machine
Both VMs are running BIND 9.11.1, and all are on various versions of
Slackware Linux.
The plan is to migrate all masters to Master and to use catz to
provision the two VMs. As I said, this is all peachy and smooth on
VM2 (many thanks to Mukund and ISC for that.)
I have run into trouble on VM1. My procedure has been to update the
master zones to show changes, check that the update is shown on
Master (which actually has these zones as slaves of VM1). Then I
remove the master zone on VM1 with "rndc reconfig", nsupdate the
catalog on Master.
The first batch of these went well. The next batches bombed, because
"rndc reconfig" removes all the catz member zones! I looked in my
logs and saw gazillions of REFUSED queries for my catz zones.
The last batch of 3, I saw the catz member zones removed in the logs
after reconfig. Then I added the three to the catalog. Both VM1 and
VM2 got the notify, pulled the 3 new zones and started serving them.
But the previous zones were still gone from VM1.
What I have been doing to fix it, on VM1: rndc stop, remove the
"catalog-zones" from the options{} section, start named again, then
replace the "catalog-zones" option. At that point "rndc reconfig"
adds all the member zones back.
It's very inconvenient. Am I perhaps doing something wrong, or have
I overlooked something in the documentation?
Oh, and speaking of the documentation, I think some of what's in ARM
chapter 4 should also be in ARM chapter 6. I usually expect to see
the complete documentation in chapter 6, but all it has it the very
brief syntax summary.
Thanks again for this very nice feature! Even with the pain, I'm
certain it will be beneficial in the long run.
[1] An aside: that's the aircraft call sign (as represented in FAA
computers) for the US Marine Corps helicopter when carrying the
President (or for any USMC aircraft which might happen to
transport the President, for that matter.
[2] Similarly, this would be the designation of a USMC aircraft
transporting the Vice President.[3]
[3] And all this is terribly off-topic, sorry.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
