showzone/modzone with catalog zone

Mukund Sivaraman muks at mukund.org
Wed Nov 21 11:18:03 UTC 2018


On Wed, Nov 21, 2018 at 10:08:23AM +0000, BÖSCH Christian wrote:
> Hi,
> 
> I have bind9.12.2 running.
> I populate zones with a catalog zone, which is fine.
> 
> But if I do a ‘rndc showzone <zone>’ on a slave server, I get:
> rndc: 'showzone' failed: failure

rndc showzone works only for NZF/NZD (dynamically added zones using rndc
addzone).

> In the log nothing strange:
> Nov 21 10:53:46 ns1 named[59161]: general: received control channel command 'showzone <zone>'
> Nov 21 10:53:46 ns1 named[59161]: general: loading NZD config from '_default.nzd' for zone ‘<zone>'
> 
> Then I wanted  to modify the zone config:
> rndc modzone <zone> '{ type slave; file “__catz___default_catalog_<zone>.db"; masters { <ip>; }; allow-transfer { <ip>; }; also-notify { <ip> }; };'
> zone ‘<zone>' reconfigured.

This seems like a bug, if named allowed an existing catalog zone to be
modzone'd.

> After that the showzone from above displays the new config, BUT ‘rndc reload’ doesn’t work anymore:
> 
> rndc reload
> rndc: 'reload' failed: already exists
> 
> Log:
> Nov 21 10:56:12 ns1 named[59161]: config: /usr/local/etc/namedb/options.include:32: catz: catalog zone 'catalog' will not be reconfigured
> Nov 21 10:56:12 ns1 named[59161]: general: loading NZD configs from '_default.nzd' for view '_default'
> Nov 21 10:56:12 ns1 named[59161]: config: none:1: zone ‘<zone>' already exists
> Nov 21 10:56:12 ns1 named[59161]: general: reloading configuration failed: already exists
> 
> 
> If I do a ‘rndc reload’ once more, the named process crashed and is gone:
> 
> rndc: connection to remote host closed
> This may indicate that
> * the remote server is using an older version of the command protocol,
> * this host is not authorized to connect,
> * the clocks are not synchronized, or
> * the key is invalid.
> 
> Is this a bug, or am I doing something wrong?

Ouch. If named crashed (and it is understandable given the unexpected
behavior above), it is clearly a bug. You may want to open a bug ticket
on the ISC gitlab.

		Mukund


More information about the bind-users mailing list