Catalog "reconfig" calamity

/dev/rob0 rob0 at
Fri May 26 20:24:40 UTC 2017

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, 
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.
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

More information about the bind-users mailing list