diff options
Diffstat (limited to 'doc/rfc/rfc9432.txt')
| -rw-r--r-- | doc/rfc/rfc9432.txt | 832 |
1 files changed, 832 insertions, 0 deletions
diff --git a/doc/rfc/rfc9432.txt b/doc/rfc/rfc9432.txt new file mode 100644 index 0000000..c75a8cb --- /dev/null +++ b/doc/rfc/rfc9432.txt @@ -0,0 +1,832 @@ + + + + +Internet Engineering Task Force (IETF) P. van Dijk +Request for Comments: 9432 PowerDNS +Category: Standards Track L. Peltan +ISSN: 2070-1721 CZ.NIC + O. Sury + Internet Systems Consortium + W. Toorop + NLnet Labs + C.R. Monshouwer + + P. Thomassen + deSEC, SSE - Secure Systems Engineering + A. Sargsyan + Internet Systems Consortium + July 2023 + + + DNS Catalog Zones + +Abstract + + This document describes a method for automatic DNS zone provisioning + among DNS primary and secondary name servers by storing and + transferring the catalog of zones to be provisioned as one or more + regular DNS zones. + +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). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9432. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as 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 are 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 + + The content of a DNS zone is synchronized among its primary and + secondary name servers using Authoritative Transfer (AXFR) and + Incremental Zone Transfer (IXFR). However, the list of zones served + by the primary (called a "catalog" in [RFC1035]) is not automatically + synchronized with the secondaries. To add or remove a zone, the + administrator of a DNS name server farm has to not only add or remove + the zone from the primary but must also add or remove configuration + for the zone from all secondaries. This can be both inconvenient and + error-prone. In addition, the steps required are dependent on the + name server implementation. + + 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 transfers. When entries are added to or + removed from the catalog zone, it is distributed to the secondary + name servers just like any other zone. Secondary name servers can + then add, remove, or modify the zones they serve in accordance with + the 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 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. + + Catalog zone: A DNS zone containing a DNS catalog, which is a list + of DNS zones and associated properties. + + Member zone: A DNS zone whose configuration is published inside a + catalog zone. + + Member node: A DNS name in the catalog zone representing a member + zone. + + $CATZ: Used in examples as a placeholder to represent the domain + name of the catalog zone itself. $OLDCATZ and $NEWCATZ are used to + discuss migration of a member zone from one catalog zone + ($OLDCATZ) to another catalog zone ($NEWCATZ). + + Catalog producer: An entity that generates and is responsible for + the contents of the catalog zone. + + Catalog consumer: An entity that extracts information from the + catalog zone (such as a DNS server that configures itself + according to the catalog zone's contents). + + This document makes use of terminology for transfer mechanisms (AXFR + and IXFR), record types (SOA, NS, and PTR), and other technical terms + (such as RDATA) that are specific to the DNS. Since these terms have + specific meanings in the DNS, they are not expanded upon first use in + this document. 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) primarily constitute a list of PTR records + referencing other DNS zones (so-called "member zones"). The catalog + zone may contain other records indicating additional metadata (so- + called "properties") associated with these member zones. + + Catalog consumers MUST ignore any RRs in the catalog zone for which + no processing is specified or which are otherwise not supported by + the implementation. + + Authoritative servers may be pre-configured with multiple catalog + zones, each associated with a different set of configurations. + + Although the contents of a catalog zone are interpreted and acted + upon by name servers, a catalog zone is a regular DNS zone and must + adhere to the standards for DNS zones. + + A catalog zone is primarily intended for the management of a farm of + authoritative name servers and should not be expected to be + accessible from any recursive name server. + +4. Catalog Zone Structure + + A catalog zone MUST follow the usual rules for DNS zones. In + particular, SOA and NS record sets MUST be present and adhere to + standard requirements (such as [RFC1982]). + + Although catalog zones are not intended to be queried via recursive + resolution (see Section 7), 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." is + RECOMMENDED [RFC2606] [RFC6761]. + +4.1. Member Zones + + The list of member zones is specified as a collection of member nodes + represented by domain names under the owner name "zones" where + "zones" is a direct child domain of the catalog zone. + + The names of member zones are represented on the RDATA side of a PTR + record (instead of being represented as a part of owner names) so + that all valid domain names may be represented regardless of their + length [RFC1035]. This PTR record MUST be the only record in the PTR + RRset with the same name. The presence of more than one record in + the RRset indicates a broken catalog zone that MUST NOT be processed + (see Section 5.1). + + For example, if a catalog zone lists three zones ("example.com.", + "example.net.", and "example.org."), the member node RRs would appear + as follows: + + <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. + + where <unique-N> is a label that tags each record in the collection + and has a unique value. When different <unique-N> labels hold the + same PTR value (i.e., point to the same member zone), the catalog + zone is broken and MUST NOT be processed (see Section 5.1). + + Member node labels carry no informational meaning beyond labeling + member zones. A changed label may indicate that the state for a zone + needs to be reset (see Section 5.6). + + Having the zones uniquely tagged with the <unique-N> label ensures + that additional 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 information is stored in the form of "properties". + + Properties are identified by their 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), with RR type(s) as appropriate for + the respective property. + + 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 number of RRs in the RRset) denote a broken + catalog zone, which MUST NOT be processed (see Section 5.1). + + This document includes a set of initial properties that can be + extended via the IANA registry defined and created in Section 8. + 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 Section 4.2.1. The "zones" label from + Section 4.1 can also be seen as a global property and is listed as + such in the IANA registry in Section 8. Member-specific properties + are described in Section 4.3. + + Implementers may store additional information in the catalog zone + with custom properties; see Section 4.4. The meaning of such custom + properties is determined by the implementation in question. + +4.2.1. Schema Version (version property) + + The catalog zone schema version is specified by 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: + + * zones without the version property + + * zones with a version property with more than one RR in the RRset + + * zones with a version property without an expected value in the + version.$CATZ TXT RR + + * zones with a version property with a schema version value that is + not implemented by the consumer (e.g., version "1") + + 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 is: + + version.$CATZ 0 IN TXT "2" + + Note that Version 1 was used in an earlier draft version of this memo + and reflected the implementation first found in BIND 9.11. + +4.3. Member Zone Properties + + Each member zone MAY have one or more additional properties that are + described in this section. The member properties described in this + document are all optional, and implementations MAY choose to + implement all, some, or none of them. Member zone properties are + represented by RRsets below the corresponding member node. + +4.3.1. Change of Ownership (coo property) + + The coo property facilitates controlled migration of a member zone + from one catalog to another. + + A Change Of Ownership is signaled by the coo property in the catalog + zone currently "owning" 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, if member "example.com." migrates from catalog + zone $OLDCATZ to catalog zone $NEWCATZ, this will appear in the + $OLDCATZ catalog zone as follows: + + <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. The presence of + more than one record in the RRset indicates a broken catalog zone, + which MUST NOT be processed (see Section 5.1). + + When a consumer of a catalog zone $OLDCATZ receives an update that + adds or changes a coo property for a member zone in $OLDCATZ, it does + _not_ migrate the member zone immediately. The migration has to wait + for an update of $NEWCATZ in which the member zone is present. + Before the actual migration, the consumer MUST verify that the coo + property pointing to $NEWCATZ is still present in $OLDCATZ. + + Unless the member node label (i.e., <unique-N>) for the member is the + same in $NEWCATZ, all its associated state for a just migrated zone + MUST be reset (see Section 5.6). Note that the owner of $OLDCATZ + allows for the zone-associated state to be taken over by the owner of + $NEWCATZ by default. To prevent the takeover of the zone-associated + state, the owner of $OLDCATZ must remove this state by updating the + associated properties or by performing a zone state reset (see + Section 5.6) before or simultaneous with adding the coo property (see + Section 7). + + The old owner may remove the member zone containing the coo property + from $OLDCATZ once it has been established that all its consumers + have processed the Change of Ownership. + +4.3.2. Groups (group property) + + With a group property, a consumer(s) can be signaled to treat some + member zones within the catalog zone differently. + + 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. The exact handling of the group + property value is left to the consumer's implementation and + configuration. + + The producer MAY assign a group property to all, some, or none of the + member zones within a catalog zone. The producer MAY assign more + than one group property to one member zone. This will make it + possible to transfer group information for different consumer + operators in a single catalog zone. Implementations MAY facilitate + mapping of a specific group value to a specific configuration + configurable _on a per catalog zone basis_ to allow for producers + that publish their catalog zone at multiple consumer operators. + Consumer operators SHOULD namespace their group values to reduce the + risk of having to resolve clashes. + + The consumer MUST ignore group values it does not understand. When a + consumer encounters multiple group values for a single member zone, + it MAY choose to process all, some, or none of them. This 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. Their interpretation 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. Conversely, an agreement could define + that group names starting with "operator-" indicate in which way a + given DNS operator should set up certain aspects of the member zone's + DNSSEC configuration. + + Assuming that the catalog producer and consumer(s) have established + such agreements, consider the following catalog zone (snippet) that + signals to 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 designated to indicate this combination of settings is + 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 provide + their own properties. Custom properties can occur globally or for a + specific member zone. To prevent a name clash with future + properties, such properties MUST be represented below the label + "ext". + + "ext" is not a placeholder. A custom property is named as follows: + + ; 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 + risk of clashes with other implementations of catalog zones. This + can be achieved by using two labels as the <property-prefix> so that + the name of the implementation is included in the prefix: <some- + setting>.<implementation-name>.ext.$CATZ. + + Implementations MAY use such properties on the member zone level to + store additional information about member zones (e.g., to flag them + for specific treatment). + + Further, implementations MAY use custom properties on the global + 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, then + override them using a property of the same name on the member level + (= under the ext label of the member node) if so desired. 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 expectation of + interoperability. + +5. Name Server Behavior + +5.1. General Requirements + + As it is a regular DNS zone, a catalog zone can be transferred using + DNS zone transfers among name servers. + + 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 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 (as they are treated as regular zones). + The reason a catalog zone is considered broken SHOULD be communicated + clearly to the operator (e.g., through a log message). + + When a previously correct catalog zone becomes a broken catalog zone, + it loses its catalog meaning because of an update through an + incremental transfer or otherwise. No special processing occurs. + 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 prevent 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, e.g., by an additional + update (through zone transfer or updates) fixing 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 + occurs until the zone becomes fresh again. + +5.2. Member Zone Name Clash + + If there is 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, but it should not 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 associated state data if the + zone was not configured from that specific catalog zone. The zone + and associated state (such as zone data and DNSSEC keys) MUST be + removed from the consumer when and only when the zone was configured + initially from the same catalog. Consumer operators may consider + temporarily archiving associated state to facilitate mistake + recovery. + +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 the removal of all the zone's associated + state (as described in Section 5.3), and then 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 perform migration of a member zone by + following the procedure described in Section 4.3.1. Otherwise, the + migration of 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 the member zone to $NEWCATZ. + + If in the process of a migration some consumers of the involved + catalog zones did not catch the removal of the member zone from + $OLDCATZ yet (because of a lost packet or downtime or otherwise) but + already saw the update of $NEWCATZ containing the addition of that + member zone, they may consider this update to be a name clash (see + Section 5.2) and, as a consequence, the member is not migrated to + $NEWCATZ. This possibility needs to be anticipated with a member + zone migration. Recovery from such a situation is out of the scope + of this document. For example, it may entail a manually forced + retransfer of $NEWCATZ to consumers after they have 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 a change of the member node's + name (see Section 5.4). + +6. Implementation and Operational Notes + + Although any valid domain name can be used for the catalog name + $CATZ, a catalog producer MUST NOT use names that are not under the + control of the catalog producer (with the exception of reserved + names). It is RECOMMENDED to use either a domain name owned by the + catalog producer or a domain name under a suitable name such as + "invalid." [RFC6761]. + + Catalog zones on secondary name servers would have to be set up + manually, perhaps as static configuration, similar to how ordinary + DNS zones are configured when catalog zones or another automatic + configuration mechanism are not in place. 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 automatic synchronization of the member zones for secondary + service. + + Operators of catalog consumers should note that secondary name + servers may receive DNS NOTIFY messages [RFC1996] for zones before + they are seen as newly added member zones to the catalog from which + that secondary is provisioned. + + Although they are regular DNS zones, catalog zones only contain + information for the management of a set of authoritative name + servers. To prevent unintended exposure to other parties, operators + SHOULD limit the systems able to query these zones. + + Querying/serving catalog zone contents may be inconvenient via DNS + due to the nature of their representation. Therefore, an + administrator may want to use a different method for looking at 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, it may not be + possible to 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 property (such as the list of member + zones) with a single QUERY. 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. + + 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. Hence, the catalog producer + has great power and changes must be treated carefully. For example, + if the catalog is generated by some script and this 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 + + As catalog zones are transmitted using DNS zone transfers, it is + RECOMMENDED that catalog zone transfers be protected from unexpected + modifications by way of authentication, e.g., by using 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, primary and secondary name servers for a + catalog zone may 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 + administrators may not have any administrative access to the + secondaries. + + Administrative control over what zones are 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 deemed 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, it is possible for the owner of the target catalog (i.e., + $NEWCATZ) to take over all its associated state with the zone from + the original owner (i.e., $OLDCATZ) by maintaining the same member + node label (i.e., <unique-N>). 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 Section 5.6) before or + simultaneously with 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 + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + DOI 10.17487/RFC1982, August 1996, + <https://www.rfc-editor.org/info/rfc1982>. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, + August 1996, <https://www.rfc-editor.org/info/rfc1996>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, DOI 10.17487/RFC2136, April 1997, + <https://www.rfc-editor.org/info/rfc2136>. + + [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, + <https://www.rfc-editor.org/info/rfc2606>. + + [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", + RFC 6761, DOI 10.17487/RFC6761, February 2013, + <https://www.rfc-editor.org/info/rfc6761>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, <https://www.rfc-editor.org/info/rfc8499>. + + [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., + Gudmundsson, O., and B. Wellington, "Secret Key + Transaction Authentication for DNS (TSIG)", STD 93, + RFC 8945, DOI 10.17487/RFC8945, November 2020, + <https://www.rfc-editor.org/info/rfc8945>. + + [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. + Mankin, "DNS Zone Transfer over TLS", RFC 9103, + DOI 10.17487/RFC9103, August 2021, + <https://www.rfc-editor.org/info/rfc9103>. + +9.2. Informative References + + [FOSDEM20] Vandewoestijne, L., "Extending Catalog zones - another + approach in automating maintenance", February 2020, + <https://archive.fosdem.org/2020/schedule/event/ + dns_catz/>. + + [Metazones] + Vixie, P., "Federated Domain Name Service Using DNS + Metazones", DOI 10.1093/ietcom/e89-b.4.1144, April 2006, + <https://www.semanticscholar.org/paper/Federated-Domain- + Name-Service-Using-DNS-Metazones-Vixie/ + dc12b0116332f5c236b05c71bbe20499f3c6c4b6>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +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 + + Our deepest thanks and appreciation go to Stephen Morris, Ray Bellis, + and Witold Krecicki who initiated this document and did the bulk of + the work. + + Catalog zones originated as the chosen method among various proposals + that were evaluated at Internet Systems Consortium (ISC) for easy + zone management. The chosen method of storing the catalog as a + regular DNS zone was proposed by Stephen Morris. + + The initial authors discovered that Paul Vixie's earlier [Metazones] + proposal implemented a similar approach, and they reviewed it. + Catalog zones borrow some syntax ideas from [Metazones], as both + share this scheme of representing the catalog as a regular DNS zone. + + Thanks to Leo Vandewoestijne. Leo's presentation in the DNS devroom + at FOSDEM'20 [FOSDEM20] was one of the motivations to take up and + continue the effort of standardizing catalog zones. + + 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 draft versions and offering comments and suggestions. + +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 |