Diff: rfc9432.original.xml

	rfc9432.original.xml	rfc9432.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->	<!DOCTYPE rfc [
	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-dns-catalog-zones-0	<!ENTITY nbsp " ">
	9" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.or	<!ENTITY zwsp "">
	g/2001/XInclude" consensus="true">	<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

		<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-dns-catalog-zones-0
		9" number="9432" submissionType="IETF" category="std" consensus="true" xml:lang=
		"en" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xm
		lns:xi="http://www.w3.org/2001/XInclude">

	<front>	<front>

	<title abbrev="dns-catalog-zones">DNS Catalog Zones</title><seriesInfo value="dr	<title abbrev="DNS Catalog Zones">DNS Catalog Zones</title>
	aft-ietf-dnsop-dns-catalog-zones-09" stream="IETF" status="standard" name="Inter	<seriesInfo name="RFC" value="9432"/>
	net-Draft"></seriesInfo>
	<author initials="P." surname="van Dijk" fullname="Peter van Dijk"><organization	<author initials="P." surname="van Dijk" fullname="Peter van Dijk">
	>PowerDNS</organization><address><postal><street></street>	<organization>PowerDNS</organization>
	<city>Den Haag</city>	<address><postal>
	<country>Netherlands</country>	<city>Den Haag</city>
	</postal><email>peter.van.dijk@powerdns.com</email>	<country>Netherlands</country>
	</address></author>	</postal><email>peter.van.dijk@powerdns.com</email>
	<author initials="L." surname="Peltan" fullname="Libor Peltan"><organization>CZ.	</address></author>
	NIC</organization><address><postal><street></street>
	<country>CZ</country>	<author initials="L." surname="Peltan" fullname="Libor Peltan">
	</postal><email>libor.peltan@nic.cz</email>	<organization>CZ.NIC</organization>
	</address></author>	<address><postal>
	<author initials="O." surname="Sury" fullname="Ondrej Sury"><organization>Intern	<country>Czech Republic</country>
	et Systems Consortium</organization><address><postal><street></street>	</postal><email>libor.peltan@nic.cz</email>
	<country>CZ</country>	</address></author>
	</postal><email>ondrej@isc.org</email>
	</address></author>	<author initials="O." surname="Sury" fullname="Ondrej Sury">
	<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL	<organization>Internet Systems Consortium</organization>
	net Labs</organization><address><postal><street>Science Park 400</street>	<address><postal>
	<city>Amsterdam</city>	<country>Czech Republic</country>
	<code>1098 XH</code>	</postal><email>ondrej@isc.org</email>
	<country>Netherlands</country>	</address></author>
	</postal><email>willem@nlnetlabs.nl</email>
	</address></author>	<author initials="W." surname="Toorop" fullname="Willem Toorop">
	<author initials="C.R." surname="Monshouwer" fullname="Kees Monshouwer"><organiz	<organization>NLnet Labs</organization>
	ation></organization><address><postal><street></street>	<address><postal>
	<country>Netherlands</country>	<street>Science Park 400</street>
	</postal><email>mind@monshouwer.eu</email>	<city>Amsterdam</city>
	</address></author>	<code>1098 XH</code>
	<author initials="P." surname="Thomassen" fullname="Peter Thomassen"><organizati	<country>Netherlands</country>
	on>deSEC, SSE - Secure Systems Engineering</organization><address><postal><stree	</postal><email>willem@nlnetlabs.nl</email>
	t></street>	</address></author>
	<city>Berlin</city>
	<country>Germany</country>	<author initials="C.R." surname="Monshouwer" fullname="Kees Monshouwer">
	</postal><email>peter@desec.io</email>	<organization></organization>
	</address></author>	<address><postal>
	<author initials="A." surname="Sargsyan" fullname="Aram Sargsyan"><organization>	<country>Netherlands</country>
	Internet Systems Consortium</organization><address><postal><street></street>	</postal><email>mind@monshouwer.eu</email>
	</postal><email>aram@isc.org</email>	</address></author>
	</address></author>
	<date year="2023" month="February" day="7"></date>	<author initials="P." surname="Thomassen" fullname="Peter Thomassen">
	<area>Internet</area>	<organization>deSEC, SSE - Secure Systems Engineering</organization>
	<workgroup>DNSOP Working Group</workgroup>	<address><postal>
		<street></street>
		<city>Berlin</city>
		<country>Germany</country>
		</postal><email>peter@desec.io</email>
		</address></author>

		<author initials="A." surname="Sargsyan" fullname="Aram Sargsyan">
		<organization>Internet Systems Consortium</organization>
		<address><postal>
		<street></street>
		</postal><email>aram@isc.org</email>
		</address></author>
		<date year="2023" month="July"/>
		<area>ops</area>
		<workgroup>dnsop</workgroup>

	<abstract>	<abstract>
	<t>This document describes a method for automatic DNS zone provisioning among DN S	<t>This document describes a method for automatic DNS zone provisioning among DN S

	primary and secondary nameservers by storing and transferring the catalog of	primary and secondary name servers by storing and transferring the catalog of
	zones to be provisioned as one or more regular DNS zones.</t>	zones to be provisioned as one or more regular DNS zones.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>
	<t>The content of a DNS zone is synchronized among its primary and secondary	<t>The content of a DNS zone is synchronized among its primary and secondary

	nameservers using AXFR and IXFR. However, the list of zones served by the	name servers using Authoritative Transfer (AXFR) and Incremental Zone Transfer (
	primary (called a catalog in <xref target="RFC1035"></xref>) is not automaticall	IXFR).
	y synchronized	However, the list of zones served by the
		primary (called a "catalog" in <xref target="RFC1035"></xref>) is not automatica
		lly synchronized
	with the secondaries. To add or remove a zone, the administrator of a DNS	with the secondaries. To add or remove a zone, the administrator of a DNS

	nameserver farm not only has to add or remove the zone from the primary, they	name server farm has to not only add or remove the zone from the primary but mus
	must also add/remove configuration for the zone from all secondaries. This	t also
	can be both inconvenient and error-prone; in addition, the steps required are	add or remove configuration for the zone from all secondaries. This
	dependent on the nameserver implementation.</t>	can be both inconvenient and error-prone. In addition, the steps required are
		dependent on the name server implementation.</t>
	<t>This document describes a method in which the list of zones is represented as a	<t>This document describes a method in which the list of zones is represented as a

	regular DNS zone (called a "catalog zone" here), and transferred using DNS zone	regular DNS zone (called a "catalog zone" here) and transferred using DNS zone
	transfers. When entries are added to or removed from the catalog zone, it is	transfers. When entries are added to or removed from the catalog zone, it is

	distributed to the secondary nameservers just like any other zone. Secondary	distributed to the secondary name servers just like any other zone. Secondary
	nameservers can then add/remove/modify the zones they serve in accordance with t	name servers can then add, remove, or modify the zones they serve in accordance
	he	with the
	changes to the catalog zone. Other use-cases of nameserver remote configuration	changes to the catalog zone. Other use cases of name server remote configuration
	by catalog zones are possible, where the catalog consumer might not be a	by catalog zones are possible where the catalog consumer might not be a
	secondary.</t>	secondary.</t>
	</section>	</section>

	<section anchor="terminology"><name>Terminology</name>	<section anchor="terminology"><name>Terminology</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>&	<t>
	quot;, "<bcp14>REQUIRED</bcp14>",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<b	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	cp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>&quo	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	t;, "<bcp14>MAY</bcp14>", and	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as de	be interpreted as
	scribed in	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	BCP 14 <xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and on	when, and only when, they appear in all capitals, as shown here.
	ly when, they appear in all	</t>
	capitals, as shown here.</t>

	<dl>	<dl>
	<dt>Catalog zone:</dt>	<dt>Catalog zone:</dt>

	<dd>A DNS zone containing a DNS catalog, that is, a list of DNS zones and associ ated properties.</dd>	<dd>A DNS zone containing a DNS catalog, which is a list of DNS zones and associ ated properties.</dd>
	<dt>Member zone:</dt>	<dt>Member zone:</dt>
	<dd>A DNS zone whose configuration is published inside a catalog zone.</dd>	<dd>A DNS zone whose configuration is published inside a catalog zone.</dd>
	<dt>Member node:</dt>	<dt>Member node:</dt>

	<dd>A DNS name in the Catalog zone representing a Member zone.</dd>	<dd>A DNS name in the catalog zone representing a member zone.</dd>
	<dt><tt>$CATZ</tt>:</dt>	<dt><tt>$CATZ</tt>:</dt>
	<dd>Used in examples as a placeholder to represent the domain name of the	<dd>Used in examples as a placeholder to represent the domain name of the
	catalog zone itself.	catalog zone itself.

	<tt>$OLDCATZ</tt> and <tt>$NEWCATZ</tt> are used to discuss migration of a membe r zone from one catalog zone <tt>$OLDCATZ</tt> to another catalog zone <tt>$NEWC ATZ</tt>.</dd>	<tt>$OLDCATZ</tt> and <tt>$NEWCATZ</tt> are used to discuss migration of a membe r zone from one catalog zone (<tt>$OLDCATZ</tt>) to another catalog zone (<tt>$N EWCATZ</tt>).</dd>
	<dt>Catalog producer:</dt>	<dt>Catalog producer:</dt>
	<dd>An entity that generates and is responsible for the contents of the catalog zone.</dd>	<dd>An entity that generates and is responsible for the contents of the catalog zone.</dd>
	<dt>Catalog consumer:</dt>	<dt>Catalog consumer:</dt>
	<dd>An entity that extracts information from the catalog zone (such as a DNS	<dd>An entity that extracts information from the catalog zone (such as a DNS
	server that configures itself according to the catalog zone's contents).</dd>	server that configures itself according to the catalog zone's contents).</dd>
	</dl>	</dl>

	<t>This document makes use of terminology that is specific to the DNS, such as f	<t>
	or transfer mechanisms (AXFR, IXFR), for record types (SOA, NS, PTR), and other	This document makes use of terminology for transfer mechanisms (AXFR and IXFR),
	technical terms (such as RDATA).	record types (SOA, NS, and PTR), and other technical terms (such as RDATA) that
	Since these terms have specific meanings in the DNS they are not expanded at fir	are specific to the DNS.
	st use in this document.	Since these terms have specific meanings in the DNS, they are not expanded upon
	For definitions of those and other terms, see <xref target="RFC8499"></xref>.</t	first use in this document.
	>	For definitions of these and other terms, see <xref target="RFC8499"></xref>.</t
		>
	</section>	</section>

	<section anchor="description"><name>Description</name>	<section anchor="description"><name>Description</name>

	<t>A catalog zone is a DNS zone whose contents are specially crafted. Its resour	<t>A catalog zone is a DNS zone whose contents are specially crafted. Its resour
	ce records (RR) primarily constitute a list of PTR records referencing other DNS	ce records (RRs) primarily constitute a list of PTR records referencing other DN
	zones (so-called "member zones"). The catalog zone may contain other	S zones (so-called "member zones"). The catalog zone may contain other records i
	records indicating additional metadata (so-called "properties") associ	ndicating additional metadata (so-called "properties") associated with these mem
	ated with these member zones.</t>	ber zones.</t>
	<t>Catalog consumers MUST ignore any RRs in the catalog zone for which no proces	<t>Catalog consumers <bcp14>MUST</bcp14> ignore any RRs in the catalog zone for
	sing is specified or which are otherwise not supported by the implementation.</t	which no processing is specified or which are otherwise not supported by the imp
	>	lementation.</t>
	<t>Authoritative servers may be pre-configured with multiple catalog zones, each associated with a different set of configurations.</t>	<t>Authoritative servers may be pre-configured with multiple catalog zones, each associated with a different set of configurations.</t>
	<t>Although the contents of a catalog zone are interpreted and acted upon by	<t>Although the contents of a catalog zone are interpreted and acted upon by

	nameservers, a catalog zone is a regular DNS zone and so must adhere to the	name servers, a catalog zone is a regular DNS zone and must adhere to the
	standards for DNS zones.</t>	standards for DNS zones.</t>

	<t>A catalog zone is primarily intended for the management of a farm of authorit ative nameservers, and should not be expected to be accessible from any recursiv e nameserver.</t>	<t>A catalog zone is primarily intended for the management of a farm of authorit ative name servers and should not be expected to be accessible from any recursiv e name server.</t>
	</section>	</section>

	<section anchor="catalog-zone-structure"><name>Catalog Zone Structure</name>	<section anchor="catalog-zone-structure"><name>Catalog Zone Structure</name>

	<t>A catalog zone MUST follow the usual rules for DNS zones.	<t>A catalog zone <bcp14>MUST</bcp14> follow the usual rules for DNS zones.
	In particular, SOA and NS record sets MUST be present and adhere to standard req	In particular, SOA and NS record sets <bcp14>MUST</bcp14> be present and adhere
	uirements (such as <xref target="RFC1982"></xref>).</t>	to standard requirements (such as <xref target="RFC1982"></xref>).</t>
	<t>Although catalog zones are not intended to be queried via recursive resolutio n (see <xref target="security"></xref>), at least one NS RR is still required so that a catalog zone is a syntactically correct DNS zone.	<t>Although catalog zones are not intended to be queried via recursive resolutio n (see <xref target="security"></xref>), at least one NS RR is still required so that a catalog zone is a syntactically correct DNS zone.

	A single NS RR with a NSDNAME field containing the absolute name "invalid.& quot; is RECOMMENDED <xref target="RFC2606"></xref><xref target="RFC6761"></xref >.</t>	A single NS RR with a NSDNAME field containing the absolute name "invalid." is < bcp14>RECOMMENDED</bcp14> <xref target="RFC2606"></xref> <xref target="RFC6761"> </xref>.</t>

	<section anchor="listofmemberzones"><name>Member Zones</name>	<section anchor="listofmemberzones"><name>Member Zones</name>

	<t>The list of member zones is specified as a collection of member nodes, repres	<t>The list of member zones is specified as a collection of member nodes represe
	ented by domain names under the owner name "zones" where "zones&q	nted by domain names under the owner name "zones" where "zones" is a direct chil
	uot; is a direct child domain of the catalog zone.</t>	d domain of the catalog zone.</t>
	<t>The names of member zones are represented on the RDATA side (instead of as a	<t>The names of member zones are represented on the RDATA side of a PTR record (
	part of owner names) of a PTR record, so that all valid domain names may be repr	instead of being represented as a part of owner names) so that all valid domain
	esented regardless of their length <xref target="RFC1035"></xref>.	names may be represented regardless of their length <xref target="RFC1035"></xre
	This PTR record MUST be the only record in the PTR RRset with the same name.	f>.
	The presence of more than one record in the RRset indicates a broken catalog zon	This PTR record <bcp14>MUST</bcp14> be the only record in the PTR RRset with the
	e which MUST NOT be processed (see <xref target="generalrequirements"></xref>).<	same name.
	/t>	The presence of more than one record in the RRset indicates a broken catalog zon
	<t>For example, if a catalog zone lists three zones "example.com.",	e that <bcp14>MUST NOT</bcp14> be processed (see <xref target="generalrequiremen
	"example.net." and "example.org.", the member node RRs would	ts"></xref>).</t>
	appear as follows:</t>	<t>For example, if a catalog zone lists three zones ("example.com.",
		"example.net.", and "example.org."), the member node RRs would appear as follows
		:</t>
		<sourcecode type="dns-rr"><![CDATA[
		<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.
		]]></sourcecode>


	<artwork><unique-1>.zones.$CATZ 0 IN PTR example.com.	<t>where <tt><unique-N></tt> is a label that tags each record in the colle
	<unique-2>.zones.$CATZ 0 IN PTR example.net.	ction and has a unique value.
	<unique-3>.zones.$CATZ 0 IN PTR example.org.	When different <tt><unique-N></tt> labels hold the same PTR value (i.e., p
	</artwork>	oint to the same member zone), the catalog zone is broken and <bcp14>MUST NOT</b
	<t>where <tt><unique-N></tt> is a label that tags each record in the colle	cp14> be processed (see <xref target="generalrequirements"></xref>).</t>
	ction.
	<tt><unique-N></tt> has a unique value in the collection.
	When different <tt><unique-N></tt> labels hold the same PTR value (i.e., p
	oint to the same member zone), the catalog zone is broken and MUST NOT be proces
	sed (see <xref target="generalrequirements"></xref>).</t>
	<t>Member node labels carry no informational meaning beyond labeling member zone s.	<t>Member node labels carry no informational meaning beyond labeling member zone s.
	A changed label may indicate that the state for a zone needs to be reset (see <x ref target="zonereset"></xref>).</t>	A changed label may indicate that the state for a zone needs to be reset (see <x ref target="zonereset"></xref>).</t>
	<t>Having the zones uniquely tagged with the <tt><unique-N></tt> label ens ures that additional RRs can be added below the member node (see <xref target="p roperties"></xref>).</t>	<t>Having the zones uniquely tagged with the <tt><unique-N></tt> label ens ures that additional RRs can be added below the member node (see <xref target="p roperties"></xref>).</t>

	<t>The CLASS field of every RR in a catalog zone MUST be IN (1).	<t>The CLASS field of every RR in a catalog zone <bcp14>MUST</bcp14> be IN (1).
	The TTL field's value has no meaning in this context and SHOULD be ignored.</t>	The TTL field's value has no meaning in this context and <bcp14>SHOULD</bcp14> b
		e ignored.</t>
	</section>	</section>

	<section anchor="properties"><name>Properties</name>	<section anchor="properties"><name>Properties</name>

	<t>Catalog zone information is stored in the form of "properties".</t>	<t>Catalog zone information is stored in the form of "properties".</t>
	<t>Properties are identified by their name, which is used as an owner name prefi x for one or more record sets underneath a member node (or underneath the catalo g zone apex), with RR type(s) as appropriate for the respective property.</t>	<t>Properties are identified by their name, which is used as an owner name prefi x for one or more record sets underneath a member node (or underneath the catalo g zone apex), with RR type(s) as appropriate for the respective property.</t>

	<t>Known properties with the correct RR type, but which are for some reason	<t>Known properties that have the correct RR type but are for some reason
	invalid (for example because of an impossible value or because of an illegal	invalid (for example, because of an impossible value or because of an illegal
	number of RRs in the RRset), denote a broken catalog zone which MUST NOT be	number of RRs in the RRset) denote a broken catalog zone, which <bcp14>MUST NOT<
		/bcp14> be
	processed (see <xref target="generalrequirements"></xref>).</t>	processed (see <xref target="generalrequirements"></xref>).</t>

	<t>This document includes a set of initial properties which can be extended via the IANA registry defined and created in <xref target="iana"></xref>.	<t>This document includes a set of initial properties that can be extended via t he IANA registry defined and created in <xref target="iana"></xref>.
	Some properties are defined at the global level; others are scoped to apply only to a specific member zone.	Some properties are defined at the global level; others are scoped to apply only to a specific member zone.
	This document defines a mandatory global property in <xref target="version"></xr ef>.	This document defines a mandatory global property in <xref target="version"></xr ef>.

	The "zones" label from <xref target="listofmemberzones"></xref> can al so be seen as a global property and is listed as such in the IANA registry in <x ref target="iana"></xref>.	The "zones" label from <xref target="listofmemberzones"></xref> can also be seen as a global property and is listed as such in the IANA registry in <xref target ="iana"></xref>.
	Member-specific properties are described in <xref target="memberproperties"></xr ef>.</t>	Member-specific properties are described in <xref target="memberproperties"></xr ef>.</t>

	<t>Implementers may store additional information in the catalog zone with Custom properties, see <xref target="customproperties"></xref>.	<t>Implementers may store additional information in the catalog zone with custom properties; see <xref target="customproperties"></xref>.
	The meaning of such custom properties is determined by the implementation in que stion.</t>	The meaning of such custom properties is determined by the implementation in que stion.</t>

	<section anchor="version"><name>Schema Version (<tt>version</tt> property)</name >	<section anchor="version"><name>Schema Version (<tt>version</tt> property)</name >
	<t>The catalog zone schema version is specified by an integer value embedded in a TXT RR named <tt>version.$CATZ</tt>.	<t>The catalog zone schema version is specified by an integer value embedded in a TXT RR named <tt>version.$CATZ</tt>.

	All catalog zones MUST have a TXT RRset named <tt>version.$CATZ</tt> with exactl	All catalog zones <bcp14>MUST</bcp14> have a TXT RRset named <tt>version.$CATZ</
	y one RR.</t>	tt> with exactly one RR.</t>
	<t>Catalog consumers MUST NOT apply catalog zone processing to</t>	<t>Catalog consumers <bcp14>MUST NOT</bcp14> apply catalog zone processing to:</
		t>

	<ul>	<ul>
	<li>zones without the <tt>version</tt> property</li>	<li>zones without the <tt>version</tt> property</li>
	<li>zones with a <tt>version</tt> property with more than one RR in the RRset</l i>	<li>zones with a <tt>version</tt> property with more than one RR in the RRset</l i>
	<li>zones with a <tt>version</tt> property without an expected value in the	<li>zones with a <tt>version</tt> property without an expected value in the
	<tt>version.$CATZ</tt> TXT RR</li>	<tt>version.$CATZ</tt> TXT RR</li>

	<li>zones with a <tt>version</tt> property with a schema version value which is not implemented by the consumer (e.g. version "1")</li>	<li>zones with a <tt>version</tt> property with a schema version value that is n ot implemented by the consumer (e.g., version "1")</li>
	</ul>	</ul>

	<t>These conditions signify a broken catalog zone which MUST NOT be processed (s ee	<t>These conditions signify a broken catalog zone, which <bcp14>MUST NOT</bcp14> be processed (see
	<xref target="generalrequirements"></xref>).</t>	<xref target="generalrequirements"></xref>).</t>

	<t>For this memo, the value of the <tt>version.$CATZ</tt> TXT RR MUST be set to "2", i.e.:</t>	<t>For this memo, the value of the <tt>version.$CATZ</tt> TXT RR <bcp14>MUST</bc p14> be set to "2"; that is:</t>


	<sourcecode type="dns-zone">version.$CATZ 0 IN TXT "2"	<sourcecode type="dns-rr"><![CDATA[version.$CATZ 0 IN TXT "2"
	</sourcecode>	]]></sourcecode>
	<t>NB: Version 1 was used in a draft version of this memo and reflected	<t>Note that Version 1 was used in an earlier draft version of this memo and ref
		lected
	the implementation first found in BIND 9.11.</t>	the implementation first found in BIND 9.11.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="memberproperties"><name>Member Zone Properties</name>	<section anchor="memberproperties"><name>Member Zone Properties</name>

	<t>Each member zone MAY have one or more additional properties, described in thi	<t>Each member zone <bcp14>MAY</bcp14> have one or more additional properties th
	s chapter.	at are described in this section.
	The member properties described in this document are all optional and implementa	The member properties described in this document are all optional, and implement
	tions MAY choose to implement all, some or none of them.	ations <bcp14>MAY</bcp14> choose to implement all, some, or none of them.
	Member zone properties are represented by RRsets below the corresponding member node.</t>	Member zone properties are represented by RRsets below the corresponding member node.</t>

	<section anchor="cooproperty"><name>Change of Ownership (<tt>coo</tt> property)< /name>	<section anchor="cooproperty"><name>Change of Ownership (<tt>coo</tt> property)< /name>
	<t>The <tt>coo</tt> property facilitates controlled migration of a member zone f rom one catalog to another.</t>	<t>The <tt>coo</tt> property facilitates controlled migration of a member zone f rom one catalog to another.</t>

	<t>A Change Of Ownership is signaled by the <tt>coo</tt> property in the catalog	<t>A Change Of Ownership is signaled by the <tt>coo</tt> property in the catalog
	zone currently "owning" the zone.	zone currently "owning" the zone.
	The name of the new catalog is the value of a PTR record in the relevant coo pro	The name of the new catalog is the value of a PTR record in the relevant <tt>coo
	perty in the old catalog.	</tt> property in the old catalog.
	For example if member "example.com." will migrate from catalog zone <t	For example, if member "example.com." migrates from catalog zone <tt>$OLDCATZ</t
	t>$OLDCATZ</tt> to catalog zone <tt>$NEWCATZ</tt>, this appears in the <tt>$OLDC	t> to catalog zone <tt>$NEWCATZ</tt>, this will appear in the <tt>$OLDCATZ</tt>
	ATZ</tt> catalog zone as follows:</t>	catalog zone as follows:</t>


	<artwork><unique-N>.zones.$OLDCATZ 0 IN PTR example.com.	<sourcecode type="dns-rr"><![CDATA[
	coo.<unique-N>.zones.$OLDCATZ 0 IN PTR $NEWCATZ	<unique-N>.zones.$OLDCATZ 0 IN PTR example.com.
	</artwork>	coo.<unique-N>.zones.$OLDCATZ 0 IN PTR $NEWCATZ
	<t>The PTR RRset MUST consist of a single PTR record.	]]></sourcecode>
	The presence of more than one record in the RRset indicates a broken catalog zon	<t>The PTR RRset <bcp14>MUST</bcp14> consist of a single PTR record.
	e which MUST NOT be processed (see <xref target="generalrequirements"></xref>).<	The presence of more than one record in the RRset indicates a broken catalog zon
	/t>	e, which <bcp14>MUST NOT</bcp14> be processed (see <xref target="generalrequirem
	<t>When a consumer of a catalog zone <tt>$OLDCATZ</tt> receives an update which	ents"></xref>).</t>
	adds or changes a <tt>coo</tt> property for a member zone in <tt>$OLDCATZ</tt>,	<t>When a consumer of a catalog zone <tt>$OLDCATZ</tt> receives an update that a
	it does <em>not</em> migrate the member zone immediately.	dds or changes a <tt>coo</tt> property for a member zone in <tt>$OLDCATZ</tt>, i
	The migration has to wait for an update of <tt>$NEWCATZ</tt>. in which the membe	t does <em>not</em> migrate the member zone immediately.
	r zone is present. The consumer MUST verify, before the actual migration, that <
	tt>coo</tt> property pointing to <tt>$NEWCATZ</tt> is still present in <tt>$OLDC	The migration has to wait for an update of <tt>$NEWCATZ</tt> in which the member
	ATZ</tt>.</t>	zone is present.
	<t>Unless the member node label (i.e., <tt><unique-N></tt>) for the member	Before the actual migration, the consumer <bcp14>MUST</bcp14> verify that the <t
	is the same in <tt>$NEWCATZ</tt>, all its associated state for a just migrated	t>coo</tt> property pointing to <tt>$NEWCATZ</tt> is still present in <tt>$OLDCA
	zone MUST be reset (see <xref target="zonereset"></xref>).	TZ</tt>.</t>
	Note that the owner of <tt>$OLDCATZ</tt> allows for the zone associated state to	<t>Unless the member node label (i.e., <tt><unique-N></tt>) for the member
	be taken over by the owner of <tt>$NEWCATZ</tt> by default.	is the same in <tt>$NEWCATZ</tt>, all its associated state for a just migrated
	To prevent the takeover of state, the owner of <tt>$OLDCATZ</tt> must remove thi	zone <bcp14>MUST</bcp14> be reset (see <xref target="zonereset"></xref>).
	s state by updating the associated properties or by performing a zone state rese	Note that the owner of <tt>$OLDCATZ</tt> allows for the zone-associated state to
	t (see <xref target="zonereset"></xref>) before or simultaneous with adding the	be taken over by the owner of <tt>$NEWCATZ</tt> by default.
	<tt>coo</tt> property. (see also <xref target="security"></xref>)</t>	To prevent the takeover of the zone-associated state, the owner of <tt>$OLDCATZ<
		/tt> must remove this state by updating the associated properties or by performi
		ng a zone state reset (see <xref target="zonereset"></xref>) before or simultane
		ous with adding the <tt>coo</tt> property (see <xref target="security"></xref>).
		</t>
	<t>The old owner may remove the member zone containing the <tt>coo</tt> property from <tt>$OLDCATZ</tt> once it has been established that all its consumers have processed the Change of Ownership.</t>	<t>The old owner may remove the member zone containing the <tt>coo</tt> property from <tt>$OLDCATZ</tt> once it has been established that all its consumers have processed the Change of Ownership.</t>
	</section>	</section>

	<section anchor="groups-group-property"><name>Groups (<tt>group</tt> property)</ name>	<section anchor="groups-group-property"><name>Groups (<tt>group</tt> property)</ name>

	<t>With a <tt>group</tt> property, consumer(s) can be signaled to treat some mem	<t>With a <tt>group</tt> property, a consumer(s) can be signaled to treat some m
	ber zones within the catalog zone differently.</t>	ember zones within the catalog zone differently.</t>
	<t>The consumer MAY apply different configuration options when processing member	<t>The consumer <bcp14>MAY</bcp14> apply different configuration options when pr
	zones, based on the value of the <tt>group</tt> property.	ocessing member zones, based on the value of the <tt>group</tt> property.
	A <tt>group</tt> property value is stored as the entire RDATA of a TXT record di rectly below the member node.	A <tt>group</tt> property value is stored as the entire RDATA of a TXT record di rectly below the member node.
	The exact handling of the <tt>group</tt> property value is left to the consumer' s implementation and configuration.</t>	The exact handling of the <tt>group</tt> property value is left to the consumer' s implementation and configuration.</t>

	<t>The producer MAY assign a <tt>group</tt> property to all, some, or none of th	<t>The producer <bcp14>MAY</bcp14> assign a <tt>group</tt> property to all, some
	e member zones within a catalog zone.	, or none of the member zones within a catalog zone.
	The producer MAY assign more than one <tt>group</tt> property to one member zone	The producer <bcp14>MAY</bcp14> assign more than one <tt>group</tt> property to
	. This will make it possible to transfer group information for different consume	one member zone. This will make it possible to transfer group information for di
	r operators in a single catalog zone.	fferent consumer operators in a single catalog zone.
	Implementations MAY facilitate mapping of a specific <tt>group</tt> value to spe	Implementations <bcp14>MAY</bcp14> facilitate mapping of a specific <tt>group</t
	cific configuration configurable <em>on a per catalog zone basis</em> to allow f	t> value to a specific configuration configurable <em>on a per catalog zone basi
	or producers that publish their catalog zone at multiple consumer operators.	s</em> to allow for producers that publish their catalog zone at multiple consum
	Consumer operators SHOULD namespace their group values to reduce the risk of hav	er operators.
	ing to resolve clashes.</t>	Consumer operators <bcp14>SHOULD</bcp14> namespace their <tt>group</tt> values t
	<t>The consumer MUST ignore <tt>group</tt> values it does not understand.	o reduce the risk of having to resolve clashes.</t>
	When a consumer encounters multiple <tt>group</tt> values for a single member zo	<t>The consumer <bcp14>MUST</bcp14> ignore <tt>group</tt> values it does not und
	ne, it MAY choose to process all, some or none of them. This is left to the impl	erstand.
	ementation.</t>	When a consumer encounters multiple <tt>group</tt> values for a single member zo
		ne, it <bcp14>MAY</bcp14> choose to process all, some, or none of them. This is
		left to the implementation.</t>

	<section anchor="example"><name>Example</name>	<section anchor="example"><name>Example</name>

	<t>Group properties are represented by TXT resource records. The record content	<t><tt>group</tt> properties are represented by TXT RRs. The record content
	has no pre-defined meaning. Their interpretation is purely a matter	has no pre-defined meaning. Their interpretation is purely a matter
	of agreement between the producer and the consumer(s) of the catalog.</t>	of agreement between the producer and the consumer(s) of the catalog.</t>

	<t>For example, the "foo" group could be agreed to indicate that a zon e not	<t>For example, the "foo" group could be agreed to indicate that a zone not
	be signed with DNSSEC. Conversely, an agreement could define that group names	be signed with DNSSEC. Conversely, an agreement could define that group names

	starting with "operator-" indicate in which way a given DNS operator s hould set	starting with "operator-" indicate in which way a given DNS operator should set
	up certain aspects of the member zone's DNSSEC configuration.</t>	up certain aspects of the member zone's DNSSEC configuration.</t>
	<t>Assuming that the catalog producer and consumer(s) have established such	<t>Assuming that the catalog producer and consumer(s) have established such

	agreements, consider the following catalog zone (snippet) which signals to	agreements, consider the following catalog zone (snippet) that signals to a
	consumer(s) how to treat DNSSEC for the zones "example.net." and &quot	consumer(s) how to treat DNSSEC for the zones "example.net." and "example.com.":
	;example.com.":</t>	</t>

	<artwork><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
	"


	</artwork>	<sourcecode type="dns-rr"><![CDATA[
	<t>In this scenario, consumer(s) shall, by agreement, not sign the member zone &	<unique-1>.zones.$CATZ 0 IN PTR example.com.
	quot;example.com." with DNSSEC.	group.<unique-1>.zones.$CATZ 0 IN TXT "foo"
	For "example.net.", the consumers, at two different operators, will co	<unique-2>.zones.$CATZ 0 IN PTR example.net.
	nfigure	group.<unique-2>.zones.$CATZ 0 IN TXT "operator-x-foo"
	the member zone to be signed with a specific combination of settings. The group	group.<unique-2>.zones.$CATZ 0 IN TXT "operator-y" "bar"
	value that indicates	]]></sourcecode>
	that depends on what has been agreed with each operator ("operator-x-foo&qu	<t>In this scenario, a consumer(s) shall, by agreement, not sign the member zone
	ot; vs. "operator-y" "bar").</t>	"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 <tt>group</tt> value designated to indicate this combination of settings is
		prearranged with each operator ("operator-x-foo" vs. "operator-y" "bar").</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="customproperties"><name>Custom Properties (<tt>*.ext</tt> prope rties)</name>	<section anchor="customproperties"><name>Custom Properties (<tt>*.ext</tt> prope rties)</name>
	<t>Implementations and operators of catalog zones may choose to provide their ow n properties.	<t>Implementations and operators of catalog zones may choose to provide their ow n properties.

	Custom properties can occur both globally, or for a specific member zone.	Custom properties can occur globally or for a specific member zone.
	To prevent a name clash with future properties, such properties MUST be represen	To prevent a name clash with future properties, such properties <bcp14>MUST</bcp
	ted below the label "ext".</t>	14> be represented below the label "ext".</t>
	<t>"ext" is not a placeholder. A custom property is named as follows:<	<t>"ext" is not a placeholder. A custom property is named as follows:</t>
	/t>


	<artwork>; a global custom property:	<sourcecode type="dns-rr"><![CDATA[
	<property-prefix>.ext.$CATZ	; a global custom property:
		<property-prefix>.ext.$CATZ

	; a member zone custom property:	; a member zone custom property:

	<property-prefix>.ext.<unique-N>.zones.$CATZ	<property-prefix>.ext.<unique-N>.zones.$CATZ
	</artwork>	]]></sourcecode>
	<t><tt><property-prefix></tt> may consist of one or more labels.</t>	<t><tt><property-prefix></tt> may consist of one or more labels.</t>

	<t>Implementations SHOULD namespace their custom properties to limit risk of cla	<t>Implementations <bcp14>SHOULD</bcp14> namespace their custom properties to li
	shes with other implementations of catalog zones.	mit risk of clashes with other implementations of catalog zones.
	This can be achieved by using two labels as the <tt><property-prefix></tt>	This can be achieved by using two labels as the <tt><property-prefix></tt>
	, so that the	so that the
	name of the implementation is included in the prefix: <tt><some-setting>.& lt;implementation-name>.ext.$CATZ</tt>.</t>	name of the implementation is included in the prefix: <tt><some-setting>.& lt;implementation-name>.ext.$CATZ</tt>.</t>

	<t>Implementations MAY use such properties on the member zone level to store add	<t>Implementations <bcp14>MAY</bcp14> use such properties on the member zone lev
	itional information about member zones,	el to store additional information about member zones
	for example to flag them for specific treatment.</t>	(e.g., to flag them for specific treatment).</t>
	<t>Further, implementations MAY use custom properties on the global level to sto	<t>Further, implementations <bcp14>MAY</bcp14> use custom properties on the glob
	re additional information about the catalog zone itself.	al level to store additional information about the catalog zone itself.
	While there may be many use cases for this, a plausible one is to store default values for custom properties on the global level,	While there may be many use cases for this, a plausible one is to store default values for custom properties on the global level,

	then overriding them using a property of the same name on the member level (= un	then override them using a property of the same name on the member level (= unde
	der the <tt>ext</tt> label of the member node) if so desired.	r the <tt>ext</tt> label of the member node) if so desired.
	A property agreement between producer and consumer should clearly define what se	A property agreement between producer and consumer should clearly define what se
	mantics apply, and whether a property is global, member, or both.</t>	mantics apply and whether a property is global, member, or both.</t>
	<t>The meaning of the custom properties described in this section is determined	<t>The meaning of the custom properties described in this section is determined
	by the implementation alone, without expectation of interoperability.</t>	by the implementation alone without expectation of interoperability.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="behavior"><name>Nameserver Behavior</name>	<section anchor="behavior"><name>Name Server Behavior</name>

	<section anchor="generalrequirements"><name>General Requirements</name>	<section anchor="generalrequirements"><name>General Requirements</name>
	<t>As it is a regular DNS zone, a catalog zone can be transferred using DNS zone	<t>As it is a regular DNS zone, a catalog zone can be transferred using DNS zone

	transfers among nameservers.</t>	transfers among name servers.</t>
	<t>Catalog updates should be automatic, i.e., when a nameserver that supports	<t>Catalog updates should be automatic; i.e., when a name server that supports
	catalog zones completes a zone transfer for a catalog zone, it SHOULD apply	catalog zones completes a zone transfer for a catalog zone, it <bcp14>SHOULD</bc
	changes to the catalog within the running nameserver automatically without any	p14> apply
		changes to the catalog within the running name server automatically without any
	manual intervention.</t>	manual intervention.</t>

	<t>Nameservers MAY allow loading and transfer of broken zones with incorrect	<t>Name servers <bcp14>MAY</bcp14> allow loading and transfer of broken zones wi th incorrect
	catalog zone syntax (as they are treated as regular zones).	catalog zone syntax (as they are treated as regular zones).

	The reason a catalog zone is considered broken SHOULD be communicated clearly to	The reason a catalog zone is considered broken <bcp14>SHOULD</bcp14> be communic
	the operator (e.g. through a log message).</t>	ated clearly to the operator (e.g., through a log message).</t>
	<t>When a previously correct catalog zone becomes a broken catalog zone, because	<t>When a previously correct catalog zone becomes a broken catalog zone, it lose
	of an update through an incremental transfer or otherwise, it loses its catalog	s its catalog
	meaning.	meaning because
		of an update through an incremental transfer or otherwise.
	No special processing occurs. Member zones previously configured by this catalog	No special processing occurs. Member zones previously configured by this catalog

	MUST NOT be removed or reconfigured in any way.</t>	<bcp14>MUST NOT</bcp14> be removed or reconfigured in any way.</t>
	<t>If a name server restarts with a broken catalog zone, the broken catalog SHOU	<t>If a name server restarts with a broken catalog zone, the broken catalog <bcp
	LD	14>SHOULD
	NOT prevent the name server from starting up and serving the member zones in	NOT</bcp14> prevent the name server from starting up and serving the member zone
		s in
	the last valid version of the catalog zone.</t>	the last valid version of the catalog zone.</t>

	<t>Processing of a broken catalog SHALL start (or resume) when the catalog turns	<t>Processing of a broken catalog <bcp14>SHALL</bcp14> start (or resume) when th
	into a correct catalog zone, for example by an additional update (through zone	e catalog turns
		into a correct catalog zone, e.g., by an additional update (through zone
	transfer or updates) fixing the catalog zone.</t>	transfer or updates) fixing the catalog zone.</t>
	<t>Similarly, when a catalog zone expires, it loses its catalog meaning and	<t>Similarly, when a catalog zone expires, it loses its catalog meaning and

	MUST no longer be processed as such.	<bcp14>MUST</bcp14> no longer be processed as such.
	No special processing occurs until the zone becomes fresh again.</t>	No special processing occurs until the zone becomes fresh again.</t>
	</section>	</section>


	<section anchor="nameclash"><name>Member zone name clash</name>	<section anchor="nameclash"><name>Member Zone Name Clash</name>
	<t>If there is a clash between an existing zone's name (either from an existing	<t>If there is a clash between an existing zone's name (from either an existing
	member zone or otherwise configured zone) and an incoming	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	member zone's name (via transfer or update), the new instance of the zone <bcp14
	be ignored and an error SHOULD be logged.</t>	>MUST</bcp14>
	<t>A clash between an existing member zone's name and an incoming member zone's	be ignored and an error <bcp14>SHOULD</bcp14> be logged.</t>
	name (via transfer or update), may be an attempt to migrate a zone to a differen	<t>A clash between an existing member zone's name and an incoming member zone's
	t catalog, but should not be treated as one except as described in <xref target=	name (via transfer or update) may be an attempt to migrate a zone to a different
	"cooproperty"></xref>.</t>	catalog, but it should not be treated as one except as described in <xref targe
		t="cooproperty"></xref>.</t>
	</section>	</section>


	<section anchor="zoneremoval"><name>Member zone removal</name>	<section anchor="zoneremoval"><name>Member Zone Removal</name>
	<t>When a member zone is removed from a specific catalog zone, a consumer MUST N	<t>When a member zone is removed from a specific catalog zone, a consumer <bcp14
	OT remove the zone and associated state data if the zone was not configured from	>MUST NOT</bcp14> remove the zone and associated state data if the zone was not
	that specific catalog zone.	configured from that specific catalog zone.
	Only when the zone was configured from a specific catalog zone, and the zone is	The zone and associated state (such as zone data and DNSSEC keys) <bcp14>MUST</b
	removed as a member from that specific catalog zone, the zone and associated sta	cp14> be removed from the consumer when and only when the zone was configured in
	te (such as zone data and DNSSEC keys) MUST be removed from the consumer.	itially from the same catalog.
	Consumer operators may consider to temporarily archive associated state to facil	Consumer operators may consider temporarily archiving associated state to facili
	itate mistake recovery.</t>	tate mistake recovery.</t>
	</section>	</section>


	<section anchor="namechange"><name>Member node name change</name>	<section anchor="namechange"><name>Member Node Name
	<t>When via a single update or transfer, the member node's label value (<tt><	Change</name>
	unique-N></tt>) changes, catalog consumers MUST process this as a member zone	<t>When the member node's label value (<tt><unique-N></tt>) changes via a
	removal including all the zone's associated state (as described in <xref target	single update or transfer, catalog consumers <bcp14>MUST</bcp14> process this as
	="zoneremoval"></xref>), immediately followed by processing the member as a newl	a member zone removal, including the removal of all the zone's associated state
	y to be configured zone in the same catalog.	(as described in <xref target="zoneremoval"></xref>), and then immediately proc
		ess the member as a newly added zone to be configured in the same catalog.
	</t>	</t>
	</section>	</section>


	<section anchor="zonemigration"><name>Migrating member zones between catalogs</n	<section anchor="zonemigration"><name>Migrating Member Zones between Catalogs</n
	ame>	ame>
	<t>If all consumers of the catalog zones involved support the <tt>coo</tt> prope	<t>If all consumers of the catalog zones involved support the <tt>coo</tt> prope
	rty, it is RECOMMENDED to perform migration of a member zone by following the pr	rty, it is <bcp14>RECOMMENDED</bcp14> to perform migration of a member zone by f
	ocedure described in <xref target="cooproperty"></xref>.	ollowing the procedure described in <xref target="cooproperty"></xref>. Otherwis
	Otherwise, a migration of a member zone from a catalog zone <tt>$OLDCATZ</tt> to	e, the migration of a member zone from a catalog zone <tt>$OLDCATZ</tt> to a cat
	a catalog zone <tt>$NEWCATZ</tt> has to be done by: first removing the member z	alog zone <tt>$NEWCATZ</tt> has to be done by first removing the member zone fro
	one from <tt>$OLDCATZ</tt>; second adding the member zone to <tt>$NEWCATZ</tt>.<	m <tt>$OLDCATZ</tt> and then adding the member zone to <tt>$NEWCATZ</tt>.</t>
	/t>	<t>If in the process of a migration some consumers of the involved catalog zones
	<t>If in the process of a migration some consumers of the involved catalog zones	did not catch the removal of the member zone from <tt>$OLDCATZ</tt> yet (becaus
	did not catch the removal of the member zone from <tt>$OLDCATZ</tt> yet (becaus	e of a lost packet or downtime or otherwise) but already saw the update of <tt>$
	e of a lost packet or downtime or otherwise), but did already see the update of	NEWCATZ</tt> containing the addition of that member zone, they may consider this
	<tt>$NEWCATZ</tt>, they may consider the update adding the member zone in <tt>$N	update to be a name clash (see <xref target="nameclash"></xref>) and, as a cons
	EWCATZ</tt> to be a name clash (see <xref target="nameclash"></xref>) and as a c	equence, the member is not migrated to <tt>$NEWCATZ</tt>.
	onsequence the member is not migrated to <tt>$NEWCATZ</tt>.
	This possibility needs to be anticipated with a member zone migration.	This possibility needs to be anticipated with a member zone migration.
	Recovery from such a situation is out of the scope of this document.	Recovery from such a situation is out of the scope of this document.

	It may for example entail a manually forced retransfer of <tt>$NEWCATZ</tt> to c onsumers after they have been detected to have received and processed the remova l of the member zone from <tt>$OLDCATZ</tt>.</t>	For example, it may entail a manually forced retransfer of <tt>$NEWCATZ</tt> to consumers after they have been detected to have received and processed the remov al of the member zone from <tt>$OLDCATZ</tt>.</t>
	</section>	</section>


	<section anchor="zonereset"><name>Zone-associated state reset</name>	<section anchor="zonereset"><name>Zone-Associated State Reset</name>
	<t>It may be desirable to reset state (such as zone data and DNSSEC keys) associ ated with a member zone.</t>	<t>It may be desirable to reset state (such as zone data and DNSSEC keys) associ ated with a member zone.</t>
	<t>A zone state reset may be performed by a change of the member node's name (se e <xref target="namechange"></xref>).</t>	<t>A zone state reset may be performed by a change of the member node's name (se e <xref target="namechange"></xref>).</t>
	</section>	</section>
	</section>	</section>

	<section anchor="implementationnotes"><name>Implementation and Operational Notes </name>	<section anchor="implementationnotes"><name>Implementation and Operational Notes </name>

	<t>Although any valid domain name can be used for the catalog name $CATZ, a cata	<t>Although any valid domain name can be used for the catalog name $CATZ, a cata
	log producer MUST NOT use names that are not under the control of the catalog pr	log producer <bcp14>MUST NOT</bcp14> use names that are not under the control of
	oducer (with the exception of reserved names). It is	the catalog producer (with the exception of reserved names).
	RECOMMENDED to use either a domain name owned by the catalog producer, or	It is
	to use a name under a suitable name such as "invalid." <xref target="R	<bcp14>RECOMMENDED</bcp14> to use either a domain name owned by the catalog prod
	FC6761"></xref>.</t>	ucer or a domain name under a suitable name such as "invalid." <xref target="RFC
	<t>Catalog zones on secondary nameservers would have to be set up manually, perh	6761"></xref>.</t>
	aps	<t>Catalog zones on secondary name servers would have to be set up manually, per
		haps
	as static configuration, similar to how ordinary DNS zones are configured when c atalog zones or another automatic configuration mechanism are not in place.	as static configuration, similar to how ordinary DNS zones are configured when c atalog zones or another automatic configuration mechanism are not in place.

	The secondary additionally needs to be configured as a catalog consumer for the catalog zone to enable processing of the member zones in the catalog, such as au tomatic synchronization of the member zones for secondary service.</t>	Additionally, the secondary needs to be configured as a catalog consumer for the catalog zone to enable processing of the member zones in the catalog, such as a utomatic synchronization of the member zones for secondary service.</t>
	<t>Operators of catalog consumers should note that secondary name servers may	<t>Operators of catalog consumers should note that secondary name servers may
	receive DNS NOTIFY messages <xref target="RFC1996"></xref> for zones before they are seen as	receive DNS NOTIFY messages <xref target="RFC1996"></xref> for zones before they are seen as
	newly added member zones to the catalog from which that secondary is	newly added member zones to the catalog from which that secondary is
	provisioned.</t>	provisioned.</t>

	<t>Although they are regular DNS zones, catalog zones contain only information f	<t>Although they are regular DNS zones, catalog zones only contain information f
	or	or
	the management of a set of authoritative nameservers. To prevent unintended	the management of a set of authoritative name servers. To prevent unintended
	exposure to other parties, operators SHOULD limit the systems able to query thes	exposure to other parties, operators <bcp14>SHOULD</bcp14> limit the systems abl
	e zones.</t>	e to query these zones.</t>
	<t>Querying/serving catalog zone contents may be inconvenient via DNS	<t>Querying/serving catalog zone contents may be inconvenient via DNS
	due to the nature of their representation.	due to the nature of their representation.

	An administrator may therefore want to use a different method for	Therefore, an administrator may want to use a different method for
	looking at data inside the catalog zone. Typical	looking at data inside the catalog zone. Typical
	queries might include dumping the list of member zones, dumping a member zone's	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,	effective configuration, querying a specific property value of a member zone,
	etc. Because of the structure of catalog zones, it may not be possible to	etc. Because of the structure of catalog zones, it may not be possible to

	perform these queries intuitively, or in some cases, at all, using DNS QUERY.	perform these queries intuitively, or in some cases at all, using DNS QUERY.
	For example, it is not possible to enumerate the contents of a multivalued	For example, it is not possible to enumerate the contents of a multivalued
	property (such as the list of member zones) with a single QUERY.	property (such as the list of member zones) with a single QUERY.
	Implementations are therefore advised to provide a tool that uses either the	Implementations are therefore advised to provide a tool that uses either the
	output of AXFR or an out-of-band method to perform queries on catalog zones.</t>	output of AXFR or an out-of-band method to perform queries on catalog zones.</t>

	<t>Great power comes with great responsibility: Catalog zones simplify zone	<t>Great power comes with great responsibility. Catalog zones simplify zone
	provisioning by orchestrating zones on secondary name servers from a single	provisioning by orchestrating zones on secondary name servers from a single

	data source - the catalog. Hence, the catalog producer has great power and	data source: the catalog. Hence, the catalog producer has great power and
	changes must be treated carefully. For example if the catalog is generated by	changes must be treated carefully. For example, if the catalog is generated by
	some script and this script for whatever reason generates an empty catalog,	some script and this script generates an empty catalog,
	millions of member zones may get deleted from their secondaries within seconds	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.</t>	and all the affected domains may be offline in a blink of an eye.</t>
	</section>	</section>

	<section anchor="security"><name>Security Considerations</name>	<section anchor="security"><name>Security Considerations</name>
	<t>As catalog zones are transmitted using DNS zone transfers,	<t>As catalog zones are transmitted using DNS zone transfers,

	it is RECOMMENDED that catalog zone transfers are protected from unexpected modi	it is <bcp14>RECOMMENDED</bcp14> that catalog zone transfers be protected from u
	fications by way of authentication,	nexpected modifications by way of authentication, e.g., by using a Transaction S
	for example by using TSIG <xref target="RFC8945"></xref>, or Strict or Mutual TL	ignature (TSIG) <xref target="RFC8945"></xref> or Strict or Mutual TLS authentic
	S authentication with DNS Zone transfer over TLS or QUIC <xref target="RFC9103">	ation with DNS zone transfer over TLS or QUIC <xref target="RFC9103"></xref>.</t
	</xref>.</t>	>
	<t>Use of DNS UPDATE <xref target="RFC2136"></xref> to modify the content of cat	<t>Use of DNS UPDATE <xref target="RFC2136"></xref> to modify the content of cat
	alog zones SHOULD similarly be authenticated.</t>	alog zones <bcp14>SHOULD</bcp14> similarly be authenticated.</t>
	<t>Zone transfers of member zones SHOULD similarly be authenticated.	<t>Zone transfers of member zones <bcp14>SHOULD</bcp14> similarly be authenticat
	TSIG shared secrets used for member zones SHOULD NOT be mentioned in the catalog	ed.
	zone data.	TSIG shared secrets used for member zones <bcp14>SHOULD NOT</bcp14> be mentioned
		in the catalog zone data.
	However, key identifiers may be shared within catalog zones.</t>	However, key identifiers may be shared within catalog zones.</t>
	<t>Catalog zones reveal the zones served by their consumers, including their pro perties.	<t>Catalog zones reveal the zones served by their consumers, including their pro perties.

	To prevent unintentional exposure of catalog zone contents, it is RECOMMENDED to	To prevent unintentional exposure of catalog zone contents, it is <bcp14>RECOMME
	limit the systems able to query them and to conduct catalog zone transfers conf	NDED</bcp14> to limit the systems able to query them and to conduct catalog zone
	identially <xref target="RFC9103"></xref>.</t>	transfers confidentially <xref target="RFC9103"></xref>.</t>
	<t>As with regular zones, primary and secondary nameservers for a catalog zone m	<t>As with regular zones, primary and secondary name servers for a catalog zone
	ay	may
	be operated by different administrators. The secondary nameservers may be	be operated by different administrators. The secondary name servers may be
	configured as a catalog consumer to synchronize catalog zones from the primary, but the primary's	configured as a catalog consumer to synchronize catalog zones from the primary, but the primary's
	administrators may not have any administrative access to the secondaries.</t>	administrators may not have any administrative access to the secondaries.</t>

	<t>Administrative control over what zones are served from the configured name se	<t>Administrative control over what zones are served from the configured name se
	rvers shifts completely from the server operator (consumer) to the "owner&q	rvers shifts completely from the server operator (consumer) to the "owner" (prod
	uot; (producer) of the catalog zone content.	ucer) of the catalog zone content.
	To prevent unintended provisioning of zones, consumer(s) SHOULD scope the set of	To prevent unintended provisioning of zones, a consumer(s) <bcp14>SHOULD</bcp14>
	admissible member zones by any means deemed suitable (such as statically, via	scope the set of
	regular expressions, or dynamically, by verifying against another database	admissible member zones by any means deemed suitable (such as statically via
		regular expressions, or dynamically by verifying against another database
	before accepting a member zone).</t>	before accepting a member zone).</t>
	<t>With migration of member zones between catalogs using the <tt>coo</tt> proper ty, it is possible for the owner of the target catalog (i.e., <tt>$NEWCATZ</tt>) to take over all its associated state with the zone from the original owner (i. e., <tt>$OLDCATZ</tt>) by maintaining the same member node label (i.e., <tt>< unique-N></tt>).	<t>With migration of member zones between catalogs using the <tt>coo</tt> proper ty, it is possible for the owner of the target catalog (i.e., <tt>$NEWCATZ</tt>) to take over all its associated state with the zone from the original owner (i. e., <tt>$OLDCATZ</tt>) by maintaining the same member node label (i.e., <tt>< unique-N></tt>).

	To prevent the takeover of the zone associated state, the original owner has to enforce a zone state reset by changing the member node label (see <xref target=" zonereset"></xref>) before or simultaneously with adding the <tt>coo</tt> proper ty.</t>	To prevent the takeover of the zone-associated state, the original owner has to enforce a zone state reset by changing the member node label (see <xref target=" zonereset"></xref>) before or simultaneously with adding the <tt>coo</tt> proper ty.</t>
	</section>	</section>


	<section anchor="iana"><name>IANA Considerations</name>	<section anchor="iana"><name>IANA Considerations</name>

	<t>IANA is requested to create a registry on the "Domain Name System (DNS)	<t>IANA has created the "DNS Catalog Zones Properties" registry under the "Domai
	Parameters" IANA web page as follows:</t>	n Name System (DNS) Parameters" registry as follows:</t>

	<dl>	<dl>
	<dt>Registry Name:</dt>	<dt>Registry Name:</dt>
	<dd>DNS Catalog Zones Properties</dd>	<dd>DNS Catalog Zones Properties</dd>
	<dt>Assignment Policy:</dt>	<dt>Assignment Policy:</dt>

	<dd>Expert Review, except for property prefixes ending in the label "ext&qu ot;, which are for Private Use.</dd>	<dd>Expert Review, except for property prefixes ending in the label "ext", which are for Private Use <xref target="RFC8126"/>.</dd>
	<dt>Reference:</dt>	<dt>Reference:</dt>

	<dd>[this document]</dd>	<dd>RFC 9432</dd>
	<dt>Note:</dt>	<dt>Note:</dt>

	<dd>This registry does not apply to Catalog Zones version "1", but app lies to Catalog Zones version "2" as specified in [this document].</dd >	<dd>This registry applies to Catalog Zones schema version "2" as specified in RF C 9432.</dd>
	</dl>	</dl>
	<table>	<table>

		<name>DNS Catalog Zones Properties Registry</name>
	<thead>	<thead>
	<tr>	<tr>

	<th>Property prefix</th>	<th>Property Prefix</th>
	<th>Description</th>	<th>Description</th>
	<th>Status</th>	<th>Status</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>zones</td>	<td>zones</td>
	<td>List of member zones</td>	<td>List of member zones</td>
	<td>Standards Track</td>	<td>Standards Track</td>

	<td>[this document]</td>	<td>RFC 9432</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>version</td>	<td>version</td>
	<td>Schema version</td>	<td>Schema version</td>
	<td>Standards Track</td>	<td>Standards Track</td>

	<td>[this document]</td>	<td>RFC 9432</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>coo</td>	<td>coo</td>
	<td>Change of Ownership</td>	<td>Change of Ownership</td>
	<td>Standards Track</td>	<td>Standards Track</td>

	<td>[this document]</td>	<td>RFC 9432</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>group</td>	<td>group</td>
	<td>Group</td>	<td>Group</td>
	<td>Standards Track</td>	<td>Standards Track</td>

	<td>[this document]</td>	<td>RFC 9432</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>*.ext</td>	<td>*.ext</td>
	<td>Custom properties</td>	<td>Custom properties</td>
	<td>Private Use</td>	<td>Private Use</td>

	<td>[this document]</td>	<td>RFC 9432</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table><t>The meanings of the fields are as follows:</t>	</table><t>The meanings of the fields are as follows:</t>


	<dl>	<dl>
	<dt>Property prefix:</dt>	<dt>Property prefix:</dt>

	<dd>One or more domain name labels</dd>	<dd>One or more domain name labels.</dd>
	<dt>Description:</dt>	<dt>Description:</dt>

	<dd>A human readable short description or name for the property</dd>	<dd>A human-readable short description or name for the property.</dd>
	<dt>Status:</dt>	<dt>Status:</dt>

	<dd>IETF Document status or "External" if not documented in an IETF do cument.</dd>	<dd>IETF Stream RFC status or "External" if not documented in an IETF Stream RFC .</dd>
	<dt>Reference:</dt>	<dt>Reference:</dt>
	<dd>A stable reference to the document in which this property is defined.</dd>	<dd>A stable reference to the document in which this property is defined.</dd>
	</dl>	</dl>
	</section>	</section>


	<section anchor="acknowledgements"><name>Acknowledgements</name>
	<t>Our deepest thanks and appreciation go to Stephen Morris,
	Ray Bellis and Witold Krecicki who initiated this draft and did the bulk of
	the work.</t>
	<t>Catalog zones originated as the chosen method among various proposals that we
	re
	evaluated at ISC for easy zone management. The chosen method of storing the
	catalog as a regular DNS zone was proposed by Stephen Morris.</t>
	<t>The initial authors discovered that Paul Vixie's earlier <xref target="Metazo
	nes"></xref> proposal
	implemented a similar approach and reviewed it. Catalog zones borrow some
	syntax ideas from Metazones, as both share this scheme of representing the
	catalog as a regular DNS zone.</t>
	<t>Thanks to Leo Vandewoestijne. Leo's presentation in the DNS devroom at the
	FOSDEM'20 <xref target="FOSDEM20"></xref> was one of the motivations to take up
	and continue the
	effort of standardizing catalog zones.</t>
	<t>Thanks to Joe Abley, David Blacka, Brian Conry, Klaus Darilion, Brian Dickson
	, Tony Finch, Evan Hunt, Shane Kerr, Warren Kumari, Patrik Lundin, Matthijs Mekk
	ing, Victoria Risk, Josh Soref, Petr Spacek, Michael StJohns, Carsten Strotmann
	and Tim Wicinski for reviewing draft proposals and offering comments and suggest
	ions.</t>
	</section>

	</middle>	</middle>


	<back>	<back>

	<references><name>Normative References</name>	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1982. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1982. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2606. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2606. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6761. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6761. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945. xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9103. xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9103. xml"/>
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>

		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
		xml"/>

	<reference anchor="FOSDEM20" target="https://archive.fosdem.org/2020/schedule/ev ent/dns_catz/">	<reference anchor="FOSDEM20" target="https://archive.fosdem.org/2020/schedule/ev ent/dns_catz/">
	<front>	<front>

	<title>Extending Catalog zones - another approach in automating maintenance<	<title>
	/title>	Extending Catalog zones - another approach in automating maintenance
		</title>
	<author fullname="Leo Vandewoestijne" initials="L." surname="Vandewoestijne" ></author>	<author fullname="Leo Vandewoestijne" initials="L." surname="Vandewoestijne" ></author>

	<date year="2020"></date>	<date month="February" year="2020"></date>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="Metazones" target="http://family.redbarn.org/~vixie/mz.pdf">
		<reference anchor="Metazones" target="https://www.semanticscholar.org/paper/Fede
		rated-Domain-Name-Service-Using-DNS-Metazones-Vixie/dc12b0116332f5c236b05c71bbe2
		0499f3c6c4b6">
	<front>	<front>
	<title>Federated Domain Name Service Using DNS Metazones</title>	<title>Federated Domain Name Service Using DNS Metazones</title>
	<author fullname="Paul Vixie" initials="P." surname="Vixie"></author>	<author fullname="Paul Vixie" initials="P." surname="Vixie"></author>

	<date year="2005"></date>	<date month="April" year="2006"></date>
	</front>	</front>

		<seriesInfo name="DOI" value="10.1093/ietcom/e89-b.4.1144"/>
	</reference>	</reference>
	</references>	</references>

		</references>
	<section anchor="catalog-zone-example"><name>Catalog Zone Example</name>	<section anchor="catalog-zone-example"><name>Catalog Zone Example</name>
	<t>The following is a full example of a catalog zone containing three member zon es with various properties:</t>	<t>The following is a full example of a catalog zone containing three member zon es with various properties:</t>


	<artwork>catalog.invalid. 0 SOA invalid. (	<sourcecode type="dns-rr"><![CDATA[
		catalog.invalid. 0 SOA invalid. (
	invalid. 1625079950 3600 600 2147483646 0 )	invalid. 1625079950 3600 600 2147483646 0 )
	catalog.invalid. 0 NS invalid.	catalog.invalid. 0 NS invalid.
	example.vendor.ext.catalog.invalid. 0 CNAME example.net.	example.vendor.ext.catalog.invalid. 0 CNAME example.net.

	version.catalog.invalid. 0 TXT "2"	version.catalog.invalid. 0 TXT "2"
	nj2xg5b.zones.catalog.invalid. 0 PTR example.com.	nj2xg5b.zones.catalog.invalid. 0 PTR example.com.
	nvxxezj.zones.catalog.invalid. 0 PTR example.net.	nvxxezj.zones.catalog.invalid. 0 PTR example.net.
	group.nvxxezj.zones.catalog.invalid. 0 TXT (	group.nvxxezj.zones.catalog.invalid. 0 TXT (

	"operator-x-foo" )	"operator-x-foo" )
	nfwxa33.zones.catalog.invalid. 0 PTR example.org.	nfwxa33.zones.catalog.invalid. 0 PTR example.org.
	coo.nfwxa33.zones.catalog.invalid. 0 PTR (	coo.nfwxa33.zones.catalog.invalid. 0 PTR (
	newcatz.invalid. )	newcatz.invalid. )
	group.nfwxa33.zones.catalog.invalid. 0 TXT (	group.nfwxa33.zones.catalog.invalid. 0 TXT (

	"operator-y-bar" )	"operator-y-bar" )
	metrics.vendor.ext.nfwxa33.zones.catalog.invalid. 0 CNAME (	metrics.vendor.ext.nfwxa33.zones.catalog.invalid. 0 CNAME (
	collector.example.net. )	collector.example.net. )

	</artwork>	]]></sourcecode>
	</section>	</section>

		<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name
	<section anchor="implementation-status"><name>Implementation Status</name>	>
	<t><strong>Note to the RFC Editor</strong>: please remove this entire appendix b	<t>Our deepest thanks and appreciation go to <contact fullname="Stephen Morris"/
	efore publication.</t>	>,
	<t>In the following implementation status descriptions, "DNS Catalog Zones&	<contact fullname="Ray Bellis"/>, and <contact fullname="Witold Krecicki"/> who
	quot; refers	initiated this document
	to DNS Catalog Zones version 2 as described in this document.	and did the bulk of
	Version 1 of catalog zones was initially developed by ISC for BIND, but never st	the work.</t>
	andardized in the IETF.	<t>Catalog zones originated as the chosen method among various proposals that we
	Support for version 1 catalog zones is explicitly mentioned per implementation.	re
	Support for the <tt>coo</tt> and <tt>group</tt> properties are also explicitly m	evaluated at Internet Systems Consortium (ISC) for easy zone management. The ch
	entioned per implementation.</t>	osen method of storing the
		catalog as a regular DNS zone was proposed by <contact fullname="Stephen Morris"
	<ul>	/>.</t>
	<li><t>Knot DNS 3.1 (released August 2, 2021) supports both producing and consum	<t>The initial authors discovered that <contact fullname="Paul Vixie"/>'s earlie
	ing of catalog zones, including the group property.</t>	r <xref
	</li>	target="Metazones"></xref> proposal
	<li><t>PowerDNS from version 4.7 (released October 3, 2022) supports both produc	implemented a similar approach, and they reviewed it. Catalog zones borrow some
	ing and consuming of catalog zones version 2 and consuming of catalog zones vers	syntax ideas from <xref
	ion 1.	target="Metazones"></xref>, as both share this scheme of representing the
	PowerDNS does support the <tt>coo</tt> property, and the <tt>group</tt> property	catalog as a regular DNS zone.</t>
	on the producing side.</t>	<t>Thanks to <contact fullname="Leo Vandewoestijne"/>. Leo's presentation in the
	</li>	DNS devroom at
	<li><t>Proof of concept <eref target="https://github.com/IETF-Hackathon/NSDCatZ"	FOSDEM'20 <xref target="FOSDEM20"></xref> was one of the motivations to take up
	>python scripts</eref>	and continue the
	that can be used for both generating and consuming DNS Catalog Zones with NSD	effort of standardizing catalog zones.</t>
	have been developed during the hackathon at the IETF-109.</t>	<t>Thanks to <contact fullname="Joe Abley"/>, <contact fullname="David Blacka"/>
	</li>	, <contact
	<li><t>BIND 9.18.3+ supports version 2 catalog zones as described in this docume	fullname="Brian Conry"/>, <contact fullname="Klaus Darilion"/>, <contact fullnam
	nt including the <tt>coo</tt> property, as well as version 1 catalog zones.</t>	e="Brian Dickson"/>,
	</li>	<contact fullname="Tony Finch"/>, <contact fullname="Evan Hunt"/>, <contact full
	</ul>	name="Shane Kerr"/>,
	<t>Interoperability between the above implementations has been tested during the	<contact fullname="Warren Kumari"/>, <contact fullname="Patrik Lundin"/>, <conta
	hackathon at the IETF-109.</t>	ct fullname="Matthijs
		Mekking"/>, <contact fullname="Victoria Risk"/>, <contact fullname="Josh Soref"/
		>, <contact
		fullname="Petr Spacek"/>, <contact fullname="Michael StJohns"/>, <contact fullna
		me="Carsten
		Strotmann"/>, and <contact fullname="Tim Wicinski"/> for reviewing earlier draft
		versions and offering
		comments and suggestions.</t>
	</section>	</section>


	<section anchor="change-history"><name>Change History</name>
	<t><strong>Note to the RFC Editor</strong>: please remove this entire appendix b
	efore publication.</t>

	<ul>
	<li>draft-muks-dnsop-dns-catalog-zones-00</li>
	</ul>
	<blockquote><t>Initial public draft.</t>
	</blockquote>
	<ul>
	<li>draft-muks-dnsop-dns-catalog-zones-01</li>
	</ul>
	<blockquote><t>Added Witold, Ray as authors. Fixed typos, consistency issues.
	Fixed references. Updated Area. Removed newly introduced custom
	RR TYPEs. Changed schema version to 1. Changed TSIG requirement
	from MUST to SHOULD. Removed restrictive language about use of
	DNS QUERY. When zones are introduced into a catalog zone, a
	primary SHOULD first make the new zones available for transfers
	first (instead of MUST). Updated examples, esp. use IPv6 in
	examples per Fred Baker. Add catalog zone example.</t>
	</blockquote>
	<ul>
	<li>draft-muks-dnsop-dns-catalog-zones-02</li>
	</ul>
	<blockquote><t>Addressed some review comments by Patrik Lundin.</t>
	</blockquote>
	<ul>
	<li>draft-muks-dnsop-dns-catalog-zones-03</li>
	</ul>
	<blockquote><t>Revision bump.</t>
	</blockquote>
	<ul>
	<li>draft-muks-dnsop-dns-catalog-zones-04</li>
	</ul>
	<blockquote><t>Reordering of sections into more logical order.
	Separation of multi-valued properties into their own category.</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-00</li>
	</ul>
	<blockquote><t>New authors to pickup the editor pen on this draft</t>
	<t>Remove data type definitions for zone properties
	Removing configuration of member zones through zone properties altogether</t>
	<t>Remove Open issues and discussion Appendix, which was about zone options (inc
	luding primary/secondary relationships) only.</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-01</li>
	</ul>
	<blockquote><t>Added a new section "The Serial Property", introducing
	a new mechanism
	which can help with disseminating zones from the primary to the secondary
	nameservers in a timely fashion more reliably.</t>
	<t>Three different ways to provide a "serial" property with a member z
	one are
	offered to or the workgroup for discussion.</t>
	<t>Added a new section "Implementation Status", listing production rea
	dy,
	upcoming and Proof of Concept implementations, and reporting on
	interoperability of the different implementations.</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-02</li>
	</ul>
	<blockquote><t>Adding the <tt>coo</tt> property for zone migration in a controll
	ed fashion</t>
	<t>Adding the <tt>group</tt> property for reconfigure settings of member zones
	in an atomic update</t>
	<t>Adding the <tt>epoch</tt> property to reset zone associated state in a contro
	lled fashion</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-03</li>
	</ul>
	<blockquote><t>Big cleanup!</t>
	<t>Introducing the terms catalog consumer and catalog producer</t>
	<t>Reorganized topics to create a more coherent whole</t>
	<t>Properties all have consistent format now</t>
	<t>Try to assume the least possible from implementations w.r.t.:</t>
	<t>1) Predictability of the <unique-N> IDs of member zones</t>
	<t>2) Whether or not fallback catalog zones can be found for a member</t>
	<t>3) Whether or not a catalog consumer can maintain state</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-04</li>
	</ul>
	<blockquote><t>Move Implementation status to appendix</t>
	<t>Miscellaneous textual improvements</t>
	<t><tt>coo</tt> property points to <tt>$NEWCATZ</tt> (and not <tt>zones.$NEWCATZ
	</tt>)</t>
	<t>Remove suggestion to increase serial and remove member zone from <tt>$OLDCATZ
	</tt> after migration</t>
	<t>More consistent usage of the terms catalog consumer and catalog producer thro
	ughout the document</t>
	<t>Better (safer) description of resetting refresh timers of member zones with t
	he <tt>serial</tt> property</t>
	<t>Removing a member MUST remove zone associated state</t>
	<t>Make authentication requirements a bit less prescriptive in security consider
	ations</t>
	<t>Updated implementation status for KnotDNS</t>
	<t>Describe member node name changes and update "Zone associated state rese
	t" to use that as the mechanism for it.</t>
	<t>Add Peter Thomassen as co-author</t>
	<t>Complete removal of the <tt>epoch</tt> property. We consider consumer optimi
	zations with predictable member node labels (for example based on a hash) out of
	the scope of this document.</t>
	<t>Miscellaneous editorial improvements</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-05</li>
	</ul>
	<blockquote><t>Add Kees Monshouwer as co-author</t>
	<t>Removed the "serial" property</t>
	<t>Allow custom properties on the global level</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-06</li>
	</ul>
	<blockquote><t>Move administrative control explanation to Security Consideration
	s</t>
	<t>Move comment on query methods to Implementation Notes</t>
	<t>Clarify what happens on expiry</t>
	<t>Clarify catalog consumer behavior when MUST condition is violated</t>
	<t>Better text on ordering of operations for Change of Ownership</t>
	<t>Suggest to namespace custom properties</t>
	<t>Clarify how to handle property record with wrong type</t>
	<t>Cover the case of multiple different <unique-N>'s having the same value
	</t>
	<t>Recommendations for naming catalog zones</t>
	<t>Add and operational note about notifies for not yet existing zones</t>
	<t>Add text about name server restarts with broken zones</t>
	<t>Great power comes with great responsibility (Thanks Klaus!)</t>
	<t>Mention the new BIND implementation</t>
	<t>All invalid properties cause a broken catalog zone, including invalid <tt>gro
	up</tt> and <tt>version</tt> properties.</t>
	<t>Add Aram Sargsyan as author (he did the BIND9 implementation)</t>
	<t><tt>group</tt> properties can have more than one value</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-07</li>
	</ul>
	<blockquote><t>Some spelling fixes from Tim Wicinski and Josh Soref</t>
	<t>Replace SHOULDs with MUSTs for ignoring things that are meaningless to a cata
	log consumer (Thanks Michael StJohns)</t>
	<t>Update the list of people to thank in the Acknowledgements section</t>
	<t>Mention PowerDNS support of catalog zones from version 4.7.0 onwards</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-08</li>
	</ul>
	<blockquote><t>Address AD Review comments (editorial only)</t>
	<t>When DoT is mentioned, also mention now-standardized DoQ</t>
	</blockquote>
	<ul>
	<li>draft-toorop-dnsop-dns-catalog-zones-08</li>
	</ul>
	<blockquote><t>Editorial nits from David Blacka, Lars Eggert, Russ Housley, Erik
	Kline, <u format="char-num">É</u>ric Vyncke and Paul Wouters</t>
	<t>Addes a Catalog Zone Exampla</t>
	<t>Mention that the document uses DNS specific terminology and reference RFC8499
	</t>
	<t>Added IANA Considerations sections, with a registry for Catalog Zones propert
	ies</t>
	<t>Updated Implementation status also with respect to Catalog zones version &quo
	t;1" support</t>
	<t>Updates to Rename "group properties" to "group property values
	" or "group values" to reduce confusion about who will determine
	those values (operators and not implementations)</t>
	<t>Change example group values in non descriptive names</t>
	<t>Add some more clarifications on that and how group values are determined in p
	roducer/consumer agreements</t>
	<t>Stronger checking suggestion (SHOULD instead of MAY) in accepting member zone
	s by consumers in the Security section</t>
	<t>Added mistake recovery text to the Member zone removal section</t>
	<t>Replace vague language ("meaningless") with more precise wording</t
	>
	<t>Catalog consumers that know only version "2" MUST not process versi
	on "1" catalog zones and consider it broken.</t>
	<t>The entire RDATA of a group property is it's value</t>
	</blockquote></section>

	</back>	</back>


	</rfc>	</rfc>

End of changes. 104 change blocks.
	614 lines changed or deleted	464 lines changed or added
This html diff was produced by rfcdiff 1.48.