In-Reply-To: References: <8a9f39a61a31c37e93ed7fb7d438846c@nodns4.us> <20170601194236.GA76949@isc.org> <20170602111230.GJ8339@harrier.slackbuilds.org> <20170617002055.GR8339@harrier.slackbuilds.org> MIME-Version: 1.0 X-RT-Interface: Web X-Mailer: MIME-tools 5.508 (Entity 5.508) X-RT-Original-Encoding: utf-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary Message-ID: Content-Disposition: inline RT-Send-CC: Content-Length: 1430 On Fri Jul 07 03:28:51 2017, michal wrote: > I managed to reproduce this. I do not think there are any extraordinary > prerequisites for triggering this bug: AFAICT, all it takes is to run > "rndc reconfig" on a server that slaves a catalog zone. > > The problem is caused by a bug in catz code: when named is reconfigured, > configure_catz_zone() calls dns_catz_add_zone(), which should return > ISC_R_EXISTS if the catalog zone in question already existed before; > instead, dns_catz_add_zone() returns ISC_R_SUCCESS in such case (due to > the result variable being inadvertently overwritten after it is set to > ISC_R_EXISTS), which causes configure_catz_zone() to skip attaching > member zones present in the catalog zone to the reconfigured view, > ultimately causing them to be removed from configuration. I was unable > to come up with any reasonable configuration-level workaround. > > This bug seems to have been present in the code ever since catalog zones > were initially implemented in 7a00d69909. In fact, the catz system test > in its current form is causing this bug to be triggered, it is just not > aware of it. > > Furthermore, the relevant code branch in configure_catz_zone() contains > a reference counting bug which will prevent a slave using catalog zones > from being properly shut down after it is reconfigured. > > All the above issues are addressed in branch rt45310, please review. Looks fine.