A DNS zone is usually served by multiple authoritative servers, which is actually recommended for the sake of redundancy. Large authoritative DNS operators even combine different name server implementations to avoid complete infrastructure outage in case of any software error. For synchronizing zone contents between authoritative servers, a DNS-specific mechanism is available, called zone transfer. It is well established and supported by all common DNS implementations. It enables both full zone transfer (AXFR) and incremental update (IXFR).
On the other hand, one authoritative nameserver can serve multiple DNS zones. There is a clear algorithm to select the correct zone to answer from for every incoming query. The set of zones configured at one authoritative server is, since the dawn of DNS, called zone catalog. Actually, it is quite common that a name server serves lots of zones (hundreds of thousands), e.g. in case of some hosting or DNS service provider, homing or mirroring a zone per each customer. This is challenging both for the DNS server implementation programmer, seeking data structures to maintain performance (which is actually security-wise important in the field of authoritative name servers), and the operator, who needs to carefully configure all the knobs and establish automated service monitoring.
However, the biggest challenge in operating lots of zones is that the set of zones is constantly changing. Every day, new zones are added, some removed and perhaps some demand configuration change. The programmer just needs to take care that such reconfiguration does not disrupt DNS answering from unaffected zones, but the operator has to separately re-configure each of all the operated servers, usually by modifying its configuration file and triggering a reload. Unlike standardized transfers of each individual zone contents, there is no transfer of configuration files. Moreover, different implementations unsurprisingly have various unique configuration options.
Synchronizing the set of configured zones between authoritative servers is exactly the problem that Catalog zones address. The basic idea is that the configuration is serialized into the format of common zone, and the well-established routines of zone transfers are used to synchronize it fully (AXFR) or incrementally (IXFR). The content of the Catalog zone shall be internal to the authoritative servers operation. The zones whose configuration is populated from a Catalog zone are called Member zones.
Back in 2016, the first experimental implementation of Catalog zones appeared in Bind 9.11.0a3, accompanied by a description in an IETF draft. Besides many rough edges and unresolved open issues, it could hardly be made interoperable, because it basically took many of Bind’s configuration options and serialized them into complicated Catalog zone contents. Rumors were that the implementation behaved poorly with a high number of Member zones as well, which was unfortunate since that is the niche of Catalog zones. Still, the demand for a viable solution persisted in the DNS community.
In early 2020, an informal group of interested community members established itself, including developers of several open-source DNS implementations. The first idea was that the new Catalog zones would only contain the set of Member zones and nothing else. The detailed configuration of each member zone could be taken from a template shared by all of them, as they usually need to be configured equivalently. Sometimes however, some subsets of Member zones need to be treated differently (e.g. DNSSEC-signed zones and unsigned ones). This was solved by enabling a limited set of so-called Properties of each Member zone. The Group property allows to assign a different configuration template to some of the Member zones, whereas the Coo property (Change of ownership) handles smooth transition of a Member zone between two Catalog zones. It is important that those Properties are general enough to be implementable by various software vendors.
As a result, interoperable implementations of new Catalog zones soon appeared as the releases of Knot DNS 3.1 (Aug 2021), Bind 9.18.3 (May 2022) and PowerDNS 4.7 (Oct 2022). NSD, despite investing much effort in standardization and cooperation, still relies on a rather experimental set of scripts managing Catalog zone operation on top of catalog-unaware server. The common specification has been published as RFC 9432 (Jul 2023) with the status of Proposed standard.
I consider the cooperated interoperable implementation of Catalog zones together with the published RFC document a great success for the DNS community, the users, and also myself. I believe that the multilateral cooperation contributed significantly to the overall value of the document. I’m thankful for all the cooperation and any kind of support to all the co-authors as well as CZ.NIC.
This looks like this is the end of a story, but there is much more to do. We have already made some improvements in the Knot DNS implementation based on the feedback of the growing number of users of this feature, and I’m sure there will be more.