Catalog zones are specially-formatted DNS zones that allow for easy provisioning of zones to secondary servers. The zones listed in a catalog zone are called member zones, and when a catalog is transferred and loaded on a secondary with support for catalog zones, the secondary creates the member zones automatically. This is a DNS server integral method for provisioning secondary servers without having to manually configure each secondary (even if it is via configuration management). BIND was the first server to support catalog zones, but support for them has meanwhile reached PowerDNS and Knot.

As described in this post, member zones are typically added to the catalog by, say, performing a dynamic update on the catalog. This causes the catalog zone to get its SOA serial number incremented and NOTIFY its secondaries, whereupon they transfer the catalog zone and provision themselves with the member zones, deleting members which have been removed and adding new members.

Knot has a special mode with which the catalog zone can automatically generate its content from configured zones. This is enabled with catalog-role: generate which causes the catalog zone to include member zones which have a catalog-role: member. The members are added to the specified catalog, of which there can be many.

remote:
  - id: bind1
    address: 192.168.33.4@53

template:
  - id: catzonetemplate
    catalog-role: generate
    acl: catalog_transfer

  - id: cmember # catalog member
    catalog-role: member
    catalog-zone: my-catalog
    acl: secondaries_may_transfer

zone:
  - domain: my-catalog
    template: catzonetemplate
    notify: [ bind1, bind2, ... ]
    acl: [ catalog_transfer ]

  - domain: a01
    template: cmember

  - domain: a02
    template: cmember

  - domain: b01
    template: other

So the above configuration on a Knot primary provides a catalog zone my-catalog which holds the member zones a01 and a02 but not b01`. (The latter doesn’t have a member catalog-role for our catalog.)

If I transfer the catalog zone from the primary Knot server I see its content:

$ dig @127.0.0.1 my-catalog AXFR +noall +answer +onesoa | named-compilezone -q -F text -s relative -o - my-catalog.
$ORIGIN .
$TTL 0  ; 0 seconds
my-catalog              IN SOA  invalid. invalid. (
                                1676734585 ; serial
                                3600       ; refresh (1 hour)
                                600        ; retry (10 minutes)
                                2147483646 ; expire (3550 weeks 5 days 3 hours 14 minutes 6 seconds)
                                0          ; minimum (0 seconds)
                                )
                        NS      invalid.
$ORIGIN my-catalog.
version                 TXT     "2"
$ORIGIN zones.my-catalog.
5ef8e84727fd007d        PTR     a02.
a918f34730f99351        PTR     a01.

The zone’s MNAME, RNAME, and NS are generated as “invalid” which is fine for most purposes, and should we need to modify that we can simply not use the generate function but manage the catalog zone “manually”.

(I was curious as to what Knot uses for the unique member names, as they’re shorter than a SHA-1. If I read the source code correctly, they opted for a SipHash-2-4 keyed with a timestamp.)

The good news for me in a current project is that Knot’s catalog zones are compatible with BIND’s (to be expected), and the automatic member zone addition will make the administrators’ lives easier.