RFC 9432

DNS Catalog Zones

📅 published July 2023, from ietf

RFC 9432: DNS Catalog Zones ✨

Okay bestie, let's get into it! 🎀 RFC 9432 is called DNS Catalog Zones, and it's an IETF Standards Track document dated July 2023 (ISSN 2070-1721). It was written by P. van Dijk (PowerDNS), L. Peltan (CZ.NIC), O. Sury (Internet Systems Consortium), W. Toorop (NLnet Labs), C.R. Monshouwer, P. Thomassen (deSEC, SSE - Secure Systems Engineering), and A. Sargsyan (Internet Systems Consortium). The title block doesn't list anything it obsoletes or updates, so this one is standing on its own 💅

Abstract

Okay so the big idea here is automatic DNS zone provisioning 🌸 It helps primary and secondary name servers set up zones on their own. The trick is that the catalog of zones to be provisioned gets stored as, and transferred as, one or more totally regular DNS zones. Iconic, right? ✨

Status of This Memo

This is an Internet Standards Track document. 🦋

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9432 💜

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please review those documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🫶

Table of Contents 🍓

   1.  Introduction
   2.  Terminology
   3.  Description
   4.  Catalog Zone Structure
     4.1.  Member Zones
     4.2.  Properties
       4.2.1.  Schema Version (version property)
     4.3.  Member Zone Properties
       4.3.1.  Change of Ownership (coo property)
       4.3.2.  Groups (group property)
     4.4.  Custom Properties (*.ext properties)
   5.  Name Server Behavior
     5.1.  General Requirements
     5.2.  Member Zone Name Clash
     5.3.  Member Zone Removal
     5.4.  Member Node Name Change
     5.5.  Migrating Member Zones between Catalogs
     5.6.  Zone-Associated State Reset
   6.  Implementation and Operational Notes
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Catalog Zone Example
   Acknowledgements
   Authors' Addresses

1. Introduction 🌷

Okay, so the contents of a DNS zone get synced between the primary and secondary name servers using AXFR and IXFR. Cute! 🥰 But the list of zones the primary serves (which [RFC1035] calls a "catalog") does NOT get synced to the secondaries automatically 😭 So whenever you add or remove a zone, the admin of a name server farm has to add or remove it on the primary AND set up the config on every single secondary. That's both annoying and super easy to mess up. And the exact steps depend on which name server implementation you're running 💀

So this doc says: what if the list of zones was just... a regular DNS zone (a "catalog zone" here)? Then it gets shipped around with normal zone transfers 🦋 When you add or remove entries in the catalog zone, the secondaries get the update like any other zone. They can then add, remove, or change their zones to match. And catalog zones can do remote config for other stuff too, where the consumer isn't even a secondary 👑

2. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀

Let's get the vocab down 📝

  • Catalog zone: A DNS zone that holds a DNS catalog, which is a list of DNS zones plus their associated properties.
  • Member zone: A DNS zone whose config is published inside a catalog zone.
  • Member node: A DNS name in the catalog zone that stands in for a member zone.
  • $CATZ: Used in the examples as a placeholder for the domain name of the catalog zone itself. $OLDCATZ and $NEWCATZ are used when we talk about migrating a member zone from one catalog zone ($OLDCATZ) to another ($NEWCATZ) 🔁
  • Catalog producer: An entity that generates the catalog zone and is responsible for what's in it.
  • Catalog consumer: An entity that pulls information out of the catalog zone (like a DNS server that configures itself based on what's in there) 🧚

This doc also uses terms for transfer mechanisms (AXFR and IXFR), record types (SOA, NS, and PTR), and other techy stuff (like RDATA) that are specific to DNS. Since these have specific meanings in DNS, they aren't explained again the first time they show up here. For definitions of these and other terms, see [RFC8499] 🤓

3. Description 🧚

A catalog zone is a DNS zone whose contents are specially crafted ✨ Its resource records (RRs) are mainly a list of PTR records that point at other DNS zones (the so-called "member zones"). The catalog zone can also hold other records with extra metadata (the so-called "properties") about those member zones 💖

Catalog consumers MUST ignore any RRs in the catalog zone that have no specified processing or that the implementation doesn't support. 🙈

Authoritative servers can be pre-configured with multiple catalog zones, and each one can be tied to a different set of configs 🌈

Even though name servers are the ones reading and acting on the catalog zone's contents, it's still a regular DNS zone, so it has to follow the standards for DNS zones 💅

A catalog zone is mainly for managing a farm of authoritative name servers, so it shouldn't be expected to be reachable from any recursive name server 🙅‍♀️

4. Catalog Zone Structure 🎀

A catalog zone MUST follow the usual rules for DNS zones. In particular, the SOA and NS record sets MUST be present and adhere to standard requirements (such as [RFC1982]). 📋

Catalog zones aren't meant to get queried through recursive resolution (see Section 7), but at least one NS RR is still required so the catalog zone is a syntactically correct DNS zone. A single NS RR whose NSDNAME field holds the absolute name invalid. is RECOMMENDED [RFC2606] [RFC6761]. 🫣

4.1. Member Zones 🌸

The list of member zones is a collection of member nodes, each represented by a domain name under the owner name zones. zones is a direct child domain of the catalog zone 🌷

The names of member zones go on the RDATA side of a PTR record (instead of being part of owner names). That way, all valid domain names can be represented no matter how long they are [RFC1035] 📏 This PTR record MUST be the only record in the PTR RRset with the same name. If the RRset has more than one record, that means the catalog zone is broken and MUST NOT be processed (see Section 5.1) 💀

Here's an example. If a catalog zone lists three zones ("example.com.", "example.net.", and "example.org."), the member node RRs look like this:

<unique-1>.zones.$CATZ 0 IN PTR example.com.
<unique-2>.zones.$CATZ 0 IN PTR example.net.
<unique-3>.zones.$CATZ 0 IN PTR example.org.

Here <unique-N> is a label that tags each record in the collection, and it has a unique value. If different <unique-N> labels hold the same PTR value (meaning they point to the same member zone), the catalog zone is broken and MUST NOT be processed (see Section 5.1) 🚫

Member node labels don't carry any meaning beyond labeling member zones 🏷️ A changed label might mean the state for a zone needs to be reset (see Section 5.6).

Having each zone uniquely tagged with a <unique-N> label makes sure extra RRs can be added below the member node (see Section 4.2) 🧩

The CLASS field of every RR in a catalog zone MUST be IN (1). The TTL field's value has no meaning in this context and SHOULD be ignored. ⏱️

4.2. Properties 🦋

Catalog zone info is stored as "properties" ✨

A property is identified by its name, which is used as an owner name prefix for one or more record sets underneath a member node (or underneath the catalog zone apex). The RR type(s) depend on the property 🏷️

Known properties that have the right RR type but are invalid for some reason (like an impossible value or an illegal number of RRs in the RRset) mean the catalog zone is broken, and it MUST NOT be processed (see Section 5.1) 😱

This doc includes a starter set of properties, and that set can be extended through the IANA registry defined and created in Section 8 📚 Some properties are global; others are scoped to apply only to one specific member zone. This doc defines one mandatory global property in Section 4.2.1. The "zones" label from Section 4.1 can also be seen as a global property, and it's listed that way in the IANA registry in Section 8. Member-specific properties are in Section 4.3 🌈

Implementers can store extra info in the catalog zone with custom properties (see Section 4.4). What those custom properties mean is up to the implementation in question 🧑‍💻

4.2.1. Schema Version (version property) 🔥

The catalog zone schema version is an integer value embedded in a TXT RR named version.$CATZ. All catalog zones MUST have a TXT RRset named version.$CATZ with exactly one RR. 🎯

Catalog consumers MUST NOT apply catalog zone processing to any of these:

  • zones without the version property
  • zones with a version property that has more than one RR in the RRset
  • zones with a version property that doesn't have an expected value in the version.$CATZ TXT RR
  • zones with a version property whose schema version value isn't implemented by the consumer (for example, version "1")

All of these conditions signify a broken catalog zone, which MUST NOT be processed (see Section 5.1). 🚨

For this memo, the value of the version.$CATZ TXT RR MUST be set to "2". That looks like this:

version.$CATZ 0 IN TXT "2"

Fun fact: Version 1 was used in an earlier draft version of this memo, and it reflected the implementation first found in BIND 9.11 🕰️

4.3. Member Zone Properties ✨

Okay bestie, each member zone MAY have one or more extra properties, and this section covers them 💅 Every property here is optional, so implementations MAY choose to implement all, some, or none of them 🫶 Member zone properties live as RRsets right below the matching member node 🎀

4.3.1. Change of Ownership (coo property)

The coo property is how a member zone gets migrated from one catalog to another without drama 🦋

A Change Of Ownership gets signaled by the coo property in whichever catalog zone currently "owns" the zone 👑 The name of the new catalog is the value of a PTR record in the relevant coo property in the old catalog. For example, say member "example.com." moves from $OLDCATZ to $NEWCATZ. The $OLDCATZ catalog zone would show it like this:

<unique-N>.zones.$OLDCATZ 0 IN PTR example.com.
coo.<unique-N>.zones.$OLDCATZ 0 IN PTR $NEWCATZ

The PTR RRset MUST consist of a single PTR record 💖 If there's more than one record in the RRset, that means the catalog zone is broken, and it MUST NOT be processed (see Section 5.1). Not vibing with that, so don't do it 🙈

When a consumer of the catalog zone $OLDCATZ gets an update that adds or changes a coo property for a member zone in $OLDCATZ, it does _not_ migrate the zone right away 🛑 The migration has to wait for an update of $NEWCATZ where the member zone is present ✨ Before the actual migration happens, the consumer MUST verify that the coo property pointing to $NEWCATZ is still present in $OLDCATZ. Double-check energy, always 💅

Unless the member node label (i.e., <unique-N>) for the member is the same in $NEWCATZ, all of its associated state for a just migrated zone MUST be reset (see Section 5.6). Lowkey important: the owner of $OLDCATZ allows the zone-associated state to be taken over by the owner of $NEWCATZ by default 👀 If the owner of $OLDCATZ wants to stop that takeover, they have to remove this state by updating the associated properties, or by doing a zone state reset (see Section 5.6), before or at the same time as adding the coo property (see Section 7). Protect that state like it's your diary 📔🔐

Once it's been established that all of its consumers have processed the Change of Ownership, the old owner may remove the member zone containing the coo property from $OLDCATZ 🧚

4.3.2. Groups (group property)

Groups let a consumer, or a group of consumers, treat some member zones in the catalog zone differently 🌈 It's giving sorting hat energy 🧙

The consumer MAY apply different configuration options when processing member zones, based on the value of the group property. A group property value is stored as the entire RDATA of a TXT record directly below the member node 🍓 How the group property value gets handled is left up to the consumer's implementation and configuration, so no two consumers have to do it the same way 🤷‍♀️

The producer MAY assign a group property to all, some, or none of the member zones within a catalog zone 🎀 The producer MAY also assign more than one group property to a single member zone 💜 This makes it possible to transfer group information for different consumer operators in one single catalog zone, which is so efficient it's kind of iconic 👑 Implementations MAY facilitate mapping a specific group value to a specific configuration, configurable _on a per catalog zone basis_, so producers who publish their catalog zone at multiple consumer operators can keep things tidy 🧚 Consumer operators SHOULD namespace their group values, which helps reduce the risk of having to sort out clashes later 🫶

The consumer MUST ignore group values it doesn't understand 🙅‍♀️ When a consumer runs into multiple group values for a single member zone, it MAY choose to process all, some, or none of them. That part is left to the implementation 🦋

4.3.2.1. Example

Group properties are represented by TXT RRs 🌸 The record content has no pre-defined meaning. How they're interpreted is purely a matter of agreement between the producer and the consumer(s) of the catalog 🤝

For example, the "foo" group could be agreed to indicate that a zone not be signed with DNSSEC 🔐 On the flip side, an agreement could define that group names starting with "operator-" indicate how a given DNS operator should set up certain aspects of the member zone's DNSSEC configuration 🎀

Assuming the catalog producer and consumer(s) have made agreements like these, here's a catalog zone snippet that tells a consumer(s) how to treat DNSSEC for the zones "example.net." and "example.com.":

<unique-1>.zones.$CATZ        0 IN PTR    example.com.
group.<unique-1>.zones.$CATZ  0 IN TXT    "foo"
<unique-2>.zones.$CATZ        0 IN PTR    example.net.
group.<unique-2>.zones.$CATZ  0 IN TXT    "operator-x-foo"
group.<unique-2>.zones.$CATZ  0 IN TXT    "operator-y" "bar"

In this scenario, a consumer(s) shall, by agreement, not sign the member zone "example.com." with DNSSEC 🙅‍♀️ For "example.net.", the consumers at two different operators will configure the member zone to be signed with a specific combination of settings 🔥 The group value that signals this combination gets prearranged with each operator ("operator-x-foo" vs. "operator-y" "bar") 💅

4.4. Custom Properties (*.ext properties)

Implementations and operators of catalog zones may choose to make their own properties 🌈 Custom properties can be global, or they can be for one specific member zone ✨ To prevent a name clash with future properties, custom properties MUST be represented below the label "ext" 🛡️

"ext" is not a placeholder, so don't swap it out for something else 🙈 A custom property is named like this:

; a global custom property:
<property-prefix>.ext.$CATZ

; a member zone custom property:
<property-prefix>.ext.<unique-N>.zones.$CATZ

<property-prefix> may consist of one or more labels 🍓

Implementations SHOULD namespace their custom properties to limit the risk of clashes with other implementations of catalog zones 💜 One way to do this is to use two labels as the <property-prefix>, so the implementation's name is part of the prefix: <some-setting>.<implementation-name>.ext.$CATZ 🎀

Implementations MAY use these properties at the member zone level to store extra information about member zones, like flagging them for special treatment 🚩 Implementations MAY also use custom properties at the global level to store extra information about the catalog zone itself 🌸 There are lots of use cases, but a plausible one is storing default values for custom properties at the global level, then overriding them with a property of the same name at the member level (= under the ext label of the member node) if you want 🦋 A property agreement between producer and consumer should clearly define what semantics apply, and whether a property is global, member, or both ✨

The meaning of the custom properties described in this section is determined by the implementation alone, without any expectation of interoperability 🤷‍♀️

5. Name Server Behavior 🖥️

5.1. General Requirements

As it's a regular DNS zone, a catalog zone can be transferred among name servers using DNS zone transfers 🚚

Catalog updates should be automatic 🤖 That means when a name server that supports catalog zones finishes a zone transfer for a catalog zone, it SHOULD apply the changes to the catalog within the running name server automatically, without any manual intervention 💅

Name servers MAY allow loading and transfer of broken zones with incorrect catalog zone syntax, since they get treated as regular zones 🫠 The reason a catalog zone is considered broken SHOULD be communicated clearly to the operator, for example through a log message 📝

When a previously correct catalog zone becomes a broken one, it loses its catalog meaning because of an update through an incremental transfer or otherwise 💔 No special processing happens. Member zones previously configured by this catalog MUST NOT be removed or reconfigured in any way 🛑

If a name server restarts with a broken catalog zone, the broken catalog SHOULD NOT stop the name server from starting up and serving the member zones in the last valid version of the catalog zone 🚀

Processing of a broken catalog SHALL start (or resume) when the catalog turns into a correct catalog zone, for example after an additional update (through zone transfer or updates) fixes the catalog zone 🩹

Similarly, when a catalog zone expires, it loses its catalog meaning and MUST no longer be processed as such ⌛ No special processing happens until the zone becomes fresh again 🌱

5.2. Member Zone Name Clash

If there's a clash between an existing zone's name (from either an existing member zone or an otherwise configured zone) and an incoming member zone's name (via transfer or update), the new instance of the zone MUST be ignored, and an error SHOULD be logged 🚨

A clash between an existing member zone's name and an incoming member zone's name (via transfer or update) may be an attempt to migrate a zone to a different catalog. It shouldn't be treated as one, except as described in Section 4.3.1 👀

5.3. Member Zone Removal

When a member zone is removed from a specific catalog zone, a consumer MUST NOT remove the zone and its associated state if the zone wasn't configured from that specific catalog zone 🙅‍♀️ The zone and its associated state (such as zone data and DNSSEC keys) MUST be removed from the consumer when, and only when, the zone was initially configured from the same catalog 🗑️ Consumer operators may consider temporarily archiving associated state to make mistake recovery easier 🗂️

5.4. Member Node Name Change

When the member node's label value (<unique-N>) changes via a single update or transfer, catalog consumers MUST process this as a member zone removal, including removal of all the zone's associated state (as described in Section 5.3). Then they MUST immediately process the member as a newly added zone to be configured in the same catalog 🔄

5.5. Migrating Member Zones between Catalogs

If all consumers of the catalog zones involved support the coo property, it is RECOMMENDED to migrate a member zone by following the procedure described in Section 4.3.1 🦋 Otherwise, migrating a member zone from a catalog zone $OLDCATZ to a catalog zone $NEWCATZ has to be done by first removing the member zone from $OLDCATZ, and then adding it to $NEWCATZ 🚛

If, during a migration, some consumers of the involved catalog zones haven't caught the removal of the member zone from $OLDCATZ yet (because of a lost packet, downtime, or otherwise), but they already saw the update of $NEWCATZ containing the addition of that member zone, they may consider this update a name clash (see Section 5.2). As a result, the member is not migrated to $NEWCATZ 😬 This possibility needs to be anticipated when migrating a member zone. Recovering from a situation like this is out of scope for this document. For example, it may involve a manually forced retransfer of $NEWCATZ to consumers after they've been detected to have received and processed the removal of the member zone from $OLDCATZ 🛠️

5.6. Zone-Associated State Reset

It may be desirable to reset state (such as zone data and DNSSEC keys) associated with a member zone 🧼

A zone state reset may be performed by changing the member node's name (see Section 5.4) ✨

6. Implementation and Operational Notes 🛠️✨

Okay so, any valid domain name can be the catalog name $CATZ 🙈, but a catalog producer MUST NOT use names that aren't under their control (reserved names are the only exception 🙅‍♀️). It is RECOMMENDED to use either a domain name the producer owns or a name under something like "invalid." 💅 [RFC6761].

Catalog zones on secondary name servers have to be set up manually, kind of like regular DNS zones, when there's no catalog zone or other automatic config in place 🧚. The secondary also needs to be configured as a catalog consumer for the catalog zone, so it can process the member zones and automatically sync them for secondary service 🔁.

Operators of catalog consumers should note that secondary name servers may get DNS NOTIFY messages [RFC1996] for zones before those zones show up as newly added member zones in the catalog that the secondary is provisioned from 👀.

Even though catalog zones are regular DNS zones, they only hold info for managing a set of authoritative name servers 🎀. So to avoid unintended exposure to other parties, operators SHOULD limit the systems able to query these zones 🔒.

Querying or serving catalog zone contents can be kind of annoying over DNS because of how the data is represented 😭. So an administrator may want a different method for looking at the data inside the catalog zone. Typical queries might include dumping the list of member zones, dumping a member zone's effective configuration, querying a specific property value of a member zone, etc. Because of the structure of catalog zones, these queries may not be intuitive, or sometimes possible at all, using DNS QUERY. For example, you can't enumerate the contents of a multivalued property (like the list of member zones) with a single QUERY 🙃. So implementations are advised to provide a tool that uses either the output of AXFR or an out-of-band method to query catalog zones 🛠️.

Great power comes with great responsibility 💀. Catalog zones simplify zone provisioning by orchestrating zones on secondary name servers from a single data source: the catalog. So the catalog producer has great power, and changes need to be handled carefully. For example, if the catalog is generated by some script and that script generates an empty catalog, millions of member zones may get deleted from their secondaries within seconds, and all the affected domains may be offline in a blink of an eye 😱🫠.

7. Security Considerations 🔐

Catalog zones are transmitted using DNS zone transfers, so it is RECOMMENDED that catalog zone transfers be protected from unexpected modifications by authentication 🛡️. For example, you could use a Transaction Signature (TSIG) [RFC8945], or Strict or Mutual TLS authentication with DNS zone transfer over TLS or QUIC [RFC9103] 🔑.

Use of DNS UPDATE [RFC2136] to modify the content of catalog zones SHOULD similarly be authenticated ✍️.

Zone transfers of member zones SHOULD similarly be authenticated 🫶. TSIG shared secrets used for member zones SHOULD NOT be mentioned in the catalog zone data 🚫🤫. However, key identifiers may be shared within catalog zones 🪪.

Catalog zones reveal the zones served by their consumers, including their properties 👀. To prevent unintentional exposure of catalog zone contents, it is RECOMMENDED to limit the systems able to query them and to conduct catalog zone transfers confidentially [RFC9103] 🌸.

As with regular zones, the primary and secondary name servers for a catalog zone may be run by different administrators 🧑‍🤝‍🧑. The secondary name servers may be configured as a catalog consumer to sync catalog zones from the primary, but the primary's administrators may not have any administrative access to the secondaries 🚪.

Administrative control over which zones get served from the configured name servers shifts completely from the server operator (consumer) to the "owner" (producer) of the catalog zone content 👑. To prevent unintended provisioning of zones, a consumer(s) SHOULD scope the set of admissible member zones by any means that seem suitable, such as statically via regular expressions, or dynamically by verifying against another database before accepting a member zone 🧐.

With migration of member zones between catalogs using the coo property, the owner of the target catalog (i.e., $NEWCATZ) can take over all of its associated state with the zone from the original owner (i.e., $OLDCATZ) by keeping the same member node label (i.e., <unique-N>) 😤🚨. To prevent this takeover of the zone-associated state, the original owner has to enforce a zone state reset by changing the member node label (see Section 5.6) before or at the same time as adding the coo property 🛑💅.

8. IANA Considerations 📋

IANA has created the "DNS Catalog Zones Properties" registry under the "Domain Name System (DNS) Parameters" registry, as follows 🌈:

  • Registry Name: DNS Catalog Zones Properties
  • Assignment Policy: Expert Review, except for property prefixes ending in the label "ext", which are for Private Use [RFC8126].
  • Reference: RFC 9432
  • Note: This registry applies to Catalog Zones schema version "2" as specified in RFC 9432.
+=================+======================+===========+===========+
| Property Prefix | Description          | Status    | Reference |
+=================+======================+===========+===========+
| zones           | List of member zones | Standards | RFC 9432  |
|                 |                      | Track     |           |
+-----------------+----------------------+-----------+-----------+
| version         | Schema version       | Standards | RFC 9432  |
|                 |                      | Track     |           |
+-----------------+----------------------+-----------+-----------+
| coo             | Change of Ownership  | Standards | RFC 9432  |
|                 |                      | Track     |           |
+-----------------+----------------------+-----------+-----------+
| group           | Group                | Standards | RFC 9432  |
|                 |                      | Track     |           |
+-----------------+----------------------+-----------+-----------+
| *.ext           | Custom properties    | Private   | RFC 9432  |
|                 |                      | Use       |           |
+-----------------+----------------------+-----------+-----------+

          Table 1: DNS Catalog Zones Properties Registry

The meanings of the fields are as follows 🍓:

  • Property prefix: One or more domain name labels.
  • Description: A human-readable short description or name for the property.
  • Status: IETF Stream RFC status or "External" if not documented in an IETF Stream RFC.
  • Reference: A stable reference to the document in which this property is defined.

9. References 📚

9.1. Normative References

9.2. Informative References

Appendix A. Catalog Zone Example 🎀

The following is a full example of a catalog zone containing three member zones with various properties 💖:

catalog.invalid.                                0  SOA   invalid. (
                        invalid. 1625079950 3600 600 2147483646 0 )
catalog.invalid.                                0  NS    invalid.
example.vendor.ext.catalog.invalid.             0  CNAME example.net.
version.catalog.invalid.                        0  TXT   "2"
nj2xg5b.zones.catalog.invalid.                  0  PTR   example.com.
nvxxezj.zones.catalog.invalid.                  0  PTR   example.net.
group.nvxxezj.zones.catalog.invalid.            0  TXT   (
                        "operator-x-foo" )
nfwxa33.zones.catalog.invalid.                  0  PTR   example.org.
coo.nfwxa33.zones.catalog.invalid.              0  PTR   (
                        newcatz.invalid. )
group.nfwxa33.zones.catalog.invalid.            0  TXT   (
                        "operator-y-bar" )
metrics.vendor.ext.nfwxa33.zones.catalog.invalid. 0  CNAME (
                        collector.example.net. )

Acknowledgements ✨

Huge thanks and so much love to Stephen Morris, Ray Bellis, and Witold Krecicki 🫶 They started this whole doc and did the bulk of the work, so honestly they're the main characters here 👑

Catalog zones started as the winner among a bunch of ideas that got evaluated at Internet Systems Consortium (ISC) for making zone management easier 🦋 The idea of storing the catalog as a regular DNS zone came from Stephen Morris 💜

The first authors found out that Paul Vixie's older [Metazones] proposal had a similar approach, and they went through it. Catalog zones borrow some syntax ideas from [Metazones], since both use the same scheme of representing the catalog as a regular DNS zone 🌸

Thanks to Leo Vandewoestijne 🧚 Leo's talk in the DNS devroom at FOSDEM'20 [FOSDEM20] was one of the reasons people picked this back up and kept going on standardizing catalog zones. Iconic behavior 🔥

Thanks to Joe Abley, David Blacka, Brian Conry, Klaus Darilion, Brian Dickson, Tony Finch, Evan Hunt, Shane Kerr, Warren Kumari, Patrik Lundin, Matthijs Mekking, Victoria Risk, Josh Soref, Petr Spacek, Michael StJohns, Carsten Strotmann, and Tim Wicinski for reviewing earlier drafts and dropping comments and suggestions 💅 Y'all made this so much better, periodt ✨

Authors' Addresses

Peter van Dijk 🌈 PowerDNS Den Haag Netherlands Email: peter.van.dijk@powerdns.com

Libor Peltan 🎀 CZ.NIC Czech Republic Email: libor.peltan@nic.cz

Ondrej Sury 🍓 Internet Systems Consortium Czech Republic Email: ondrej@isc.org

Willem Toorop 🦋 NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands Email: willem@nlnetlabs.nl

Kees Monshouwer 🌸 Netherlands Email: mind@monshouwer.eu

Peter Thomassen ⭐ deSEC, SSE - Secure Systems Engineering Berlin Germany Email: peter@desec.io

Aram Sargsyan 💜 Internet Systems Consortium Email: aram@isc.org

📦 where this page comes from