On Wed May 31 15:01:18 2017, ca-isc@nodns4.us wrote:

> Software Version: BIND 9.11.1
> OS: Linux (Slackware 14.2)
> Subject:rndc reconfig wipes out catalog zone slaves
> 
> 
> Bug Detail
> ===========
> Also described at https://lists.isc.org/pipermail/bind-users/2017-
> May/098643.html et seq.
> 
> When a change is needed in a catalog zone slave server's named.conf,
> "rndc reconfig" or "rndc reload" removes all catalog zone member
> slaves.  The only fix I have is to remove the catalog-zones option
> from the slave server's options{}, stop and restart named.
> 
> This is very troublesome when these slave servers have been published
> as NS for the zones in question; clients receive REFUSED replies to
> queries, and these quickly fill up logs.
> 
> Discovered on BIND 9.11.1 on Slackware 13.37, replicated on
> 9.11.1/Slackware 14.2.

Hi Chuck,

We have a theory about what's going on here.

In your bind-users post you said that you're using a combination of rndc reconfig and nsupdate to convert the VMs (VM1 in the first instance) from being a master for a number of zones, to being a slave, provisioned using CATZ.

There may be some sequencing issues here therefore.  If VM1 still has the old zones at the point that they were being provisioned via CATZ, then this is going to fail.  If you're trying to convert VM1 from master to CATZ-provisioned in one fell swoop (i.e. with a single rndc reconfig) and not in two steps, then it could be that this is why it's breaking for you.

Could you be (just) a little bit more detailed on the migration steps?  

What was actually being altered when you did the rndc reconfig?

Another theory is around how many zones you are actually serving and an integration problem we've uncovered with using LMDB (liblmdb) as the backend new zone databased (NZD).  

How many zones are involved here, and did you build BIND 9.11 in an environment with liblmdb installed?

Cheers,

Cathy