JavaScript must be enabled in order for you to use Knowledgebase Manager Pro. However, it seems JavaScript is either disabled or not supported by your browser. To use Knowledgebase Manager Pro, enable JavaScript by changing your browser options, then try again.
Learn more.

Catalog Zones is a new BIND feature allowing easy provisioning of zones to slave servers. A "catalog zone" is a special DNS zone that contains a list of other zones to be served, along with their configuration parameters. The zones listed in a catalog zone are called "member zones". When a catalog zone is loaded or transferred to a slave server that supports this functionality, the slave server will create the member zones automatically. When the catalog zone is updated (for example, to add or delete member zones, or change their configuration parameters) those changes are immediately put into effect. Because the catalog zone is a normal DNS zone, these configuration changes can be propagated using the standard AXFR/IXFR zone transfer mechanism.

This guide shows the basic usage of catalog zones - how to add set up a master and slave provisioned using catalog zone, how to add a new zone to the catalog zone and how to possibly automate it. In this guide we'll be using three servers - master running on 10.53.0.1 and two slaves running on 10.53.0.2 and 10.53.0.3. To make it easier to try out this example on your own system, we are using unprivileged ports 5300 and 9953, for DNS and RNDC respectively.

First we create an empty catalog zone named "catalog.example" that we'll be using. It has to have NS and SOA records (just like a regular zone) and an IN TXT record which tells the server what version of the catalog zone syntax this zone uses - the current version is "1":

For both slave servers we need to slave the catalog.example zone from master and enable it as a catalog zone. The configuration for ns3 is identical to ns2 except all 10.53.0.2 addresses are replaced with 10.53.0.3:

Please remember that this is just an example configuration - in the real world you should never allow updates to everyone. Zone transfers should be protected with TSIG and catalog zones should not be open for queries.

We then launch ns1 and ns2 (in separate directories) - we'll leave ns3 for later. ns2 should download the now empty "catalog.example" zone and we should be able to query it:

To provision the zone on slave we have to add it to catalog zone, for now we'll do it using nsupdate. The long label (c5e4...) is the hex digest of the SHA1 hash of the zone name ("example.com") in wire format. The method of calculating it is shown below in catz-add.py script:

What was shown above isn't anything amazing and could be easily achieved by simply adding the zones to the slave using rndc addzone. The advantage of the Catalog Zones is that no matter how many slaves you have the zones catalog is kept in one central place - in a catalog zone, on the master server. If we now launch ns3 it will download this configured catalog zone and immediately add the previously configured example.com and example2.com zones and start serving them: