1 Internet Engineering Task Force (IETF)                       P. van Dijk   
    2 Request for Comments: 9432                                      PowerDNS   
    3 Category: Standards Track                                      L. Peltan   
    4 ISSN: 2070-1721                                                   CZ.NIC   
    5                                                                  O. Sury   
    6                                              Internet Systems Consortium   
    7                                                                W. Toorop   
    8                                                               NLnet Labs   
    9                                                          C.R. Monshouwer   
   11                                                             P. Thomassen   
   12                                  deSEC, SSE - Secure Systems Engineering   
   13                                                              A. Sargsyan   
   14                                              Internet Systems Consortium   
   15                                                                July 2023   
   18                            DNS Catalog Zones                               
   20 Abstract                                                                   
   22    This document describes a method for automatic DNS zone provisioning    
   23    among DNS primary and secondary name servers by storing and             
   24    transferring the catalog of zones to be provisioned as one or more      
   25    regular DNS zones.                                                      
   27 Status of This Memo                                                        
   29    This is an Internet Standards Track document.                           
   31    This document is a product of the Internet Engineering Task Force       
   32    (IETF).  It represents the consensus of the IETF community.  It has     
   33    received public review and has been approved for publication by the     
   34    Internet Engineering Steering Group (IESG).  Further information on     
   35    Internet Standards is available in Section 2 of RFC 7841.               
   37    Information about the current status of this document, any errata,      
   38    and how to provide feedback on it may be obtained at                    
   39    https://www.rfc-editor.org/info/rfc9432.                                
   41 Copyright Notice                                                           
   43    Copyright (c) 2023 IETF Trust and the persons identified as the         
   44    document authors.  All rights reserved.                                 
   46    This document is subject to BCP 78 and the IETF Trust's Legal           
   47    Provisions Relating to IETF Documents                                   
   48    (https://trustee.ietf.org/license-info) in effect on the date of        
   49    publication of this document.  Please review these documents            
   50    carefully, as they describe your rights and restrictions with respect   
   51    to this document.  Code Components extracted from this document must    
   52    include Revised BSD License text as described in Section 4.e of the     
   53    Trust Legal Provisions and are provided without warranty as described   
   54    in the Revised BSD License.                                             
   56 Table of Contents                                                          
   58    1.  Introduction                                                        
   59    2.  Terminology                                                         
   60    3.  Description                                                         
   61    4.  Catalog Zone Structure                                              
   62      4.1.  Member Zones                                                    
   63      4.2.  Properties                                                      
   64        4.2.1.  Schema Version (version property)                           
   65      4.3.  Member Zone Properties                                          
   66        4.3.1.  Change of Ownership (coo property)                          
   67        4.3.2.  Groups (group property)                                     
   68      4.4.  Custom Properties (*.ext properties)                            
   69    5.  Name Server Behavior                                                
   70      5.1.  General Requirements                                            
   71      5.2.  Member Zone Name Clash                                          
   72      5.3.  Member Zone Removal                                             
   73      5.4.  Member Node Name Change                                         
   74      5.5.  Migrating Member Zones between Catalogs                         
   75      5.6.  Zone-Associated State Reset                                     
   76    6.  Implementation and Operational Notes                                
   77    7.  Security Considerations                                             
   78    8.  IANA Considerations                                                 
   79    9.  References                                                          
   80      9.1.  Normative References                                            
   81      9.2.  Informative References                                          
   82    Appendix A.  Catalog Zone Example                                       
   83    Acknowledgements                                                        
   84    Authors' Addresses                                                      
   86 1.  Introduction                                                           
   88    The content of a DNS zone is synchronized among its primary and         
   89    secondary name servers using Authoritative Transfer (AXFR) and          
   90    Incremental Zone Transfer (IXFR).  However, the list of zones served    
   91    by the primary (called a "catalog" in [RFC1035]) is not automatically   
   92    synchronized with the secondaries.  To add or remove a zone, the        
   93    administrator of a DNS name server farm has to not only add or remove   
   94    the zone from the primary but must also add or remove configuration     
   95    for the zone from all secondaries.  This can be both inconvenient and   
   96    error-prone.  In addition, the steps required are dependent on the      
   97    name server implementation.                                             
   99    This document describes a method in which the list of zones is          
  100    represented as a regular DNS zone (called a "catalog zone" here) and    
  101    transferred using DNS zone transfers.  When entries are added to or     
  102    removed from the catalog zone, it is distributed to the secondary       
  103    name servers just like any other zone.  Secondary name servers can      
  104    then add, remove, or modify the zones they serve in accordance with     
  105    the changes to the catalog zone.  Other use cases of name server        
  106    remote configuration by catalog zones are possible where the catalog    
  107    consumer might not be a secondary.                                      
  109 2.  Terminology                                                            
  111    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  113    "OPTIONAL" in this document are to be interpreted as described in       
  114    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  115    capitals, as shown here.                                                
  117    Catalog zone:  A DNS zone containing a DNS catalog, which is a list     
  118       of DNS zones and associated properties.                              
  120    Member zone:  A DNS zone whose configuration is published inside a      
  121       catalog zone.                                                        
  123    Member node:  A DNS name in the catalog zone representing a member      
  124       zone.                                                                
  126    $CATZ:  Used in examples as a placeholder to represent the domain       
  127       name of the catalog zone itself. $OLDCATZ and $NEWCATZ are used to   
  128       discuss migration of a member zone from one catalog zone             
  129       ($OLDCATZ) to another catalog zone ($NEWCATZ).                       
  131    Catalog producer:  An entity that generates and is responsible for      
  132       the contents of the catalog zone.                                    
  134    Catalog consumer:  An entity that extracts information from the         
  135       catalog zone (such as a DNS server that configures itself            
  136       according to the catalog zone's contents).                           
  138    This document makes use of terminology for transfer mechanisms (AXFR    
  139    and IXFR), record types (SOA, NS, and PTR), and other technical terms   
  140    (such as RDATA) that are specific to the DNS.  Since these terms have   
  141    specific meanings in the DNS, they are not expanded upon first use in   
  142    this document.  For definitions of these and other terms, see           
  143    [RFC8499].                                                              
  145 3.  Description                                                            
  147    A catalog zone is a DNS zone whose contents are specially crafted.      
  148    Its resource records (RRs) primarily constitute a list of PTR records   
  149    referencing other DNS zones (so-called "member zones").  The catalog    
  150    zone may contain other records indicating additional metadata (so-      
  151    called "properties") associated with these member zones.                
  153    Catalog consumers MUST ignore any RRs in the catalog zone for which     
  154    no processing is specified or which are otherwise not supported by      
  155    the implementation.                                                     
  157    Authoritative servers may be pre-configured with multiple catalog       
  158    zones, each associated with a different set of configurations.          
  160    Although the contents of a catalog zone are interpreted and acted       
  161    upon by name servers, a catalog zone is a regular DNS zone and must     
  162    adhere to the standards for DNS zones.                                  
  164    A catalog zone is primarily intended for the management of a farm of    
  165    authoritative name servers and should not be expected to be             
  166    accessible from any recursive name server.                              
  168 4.  Catalog Zone Structure                                                 
  170    A catalog zone MUST follow the usual rules for DNS zones.  In           
  171    particular, SOA and NS record sets MUST be present and adhere to        
  172    standard requirements (such as [RFC1982]).                              
  174    Although catalog zones are not intended to be queried via recursive     
  175    resolution (see Section 7), at least one NS RR is still required so     
  176    that a catalog zone is a syntactically correct DNS zone.  A single NS   
  177    RR with a NSDNAME field containing the absolute name "invalid." is      
  178    RECOMMENDED [RFC2606] [RFC6761].                                        
  180 4.1.  Member Zones                                                         
  182    The list of member zones is specified as a collection of member nodes   
  183    represented by domain names under the owner name "zones" where          
  184    "zones" is a direct child domain of the catalog zone.                   
  186    The names of member zones are represented on the RDATA side of a PTR    
  187    record (instead of being represented as a part of owner names) so       
  188    that all valid domain names may be represented regardless of their      
  189    length [RFC1035].  This PTR record MUST be the only record in the PTR   
  190    RRset with the same name.  The presence of more than one record in      
  191    the RRset indicates a broken catalog zone that MUST NOT be processed    
  192    (see Section 5.1).                                                      
  194    For example, if a catalog zone lists three zones ("example.com.",       
  195    "example.net.", and "example.org."), the member node RRs would appear   
  196    as follows:                                                             
  198    <unique-1>.zones.$CATZ 0 IN PTR example.com.                            
  199    <unique-2>.zones.$CATZ 0 IN PTR example.net.                            
  200    <unique-3>.zones.$CATZ 0 IN PTR example.org.                            
  202    where <unique-N> is a label that tags each record in the collection     
  203    and has a unique value.  When different <unique-N> labels hold the      
  204    same PTR value (i.e., point to the same member zone), the catalog       
  205    zone is broken and MUST NOT be processed (see Section 5.1).             
  207    Member node labels carry no informational meaning beyond labeling       
  208    member zones.  A changed label may indicate that the state for a zone   
  209    needs to be reset (see Section 5.6).                                    
  211    Having the zones uniquely tagged with the <unique-N> label ensures      
  212    that additional RRs can be added below the member node (see             
  213    Section 4.2).                                                           
  215    The CLASS field of every RR in a catalog zone MUST be IN (1).  The      
  216    TTL field's value has no meaning in this context and SHOULD be          
  217    ignored.                                                                
  219 4.2.  Properties                                                           
  221    Catalog zone information is stored in the form of "properties".         
  223    Properties are identified by their name, which is used as an owner      
  224    name prefix for one or more record sets underneath a member node (or    
  225    underneath the catalog zone apex), with RR type(s) as appropriate for   
  226    the respective property.                                                
  228    Known properties that have the correct RR type but are for some         
  229    reason invalid (for example, because of an impossible value or          
  230    because of an illegal number of RRs in the RRset) denote a broken       
  231    catalog zone, which MUST NOT be processed (see Section 5.1).            
  233    This document includes a set of initial properties that can be          
  234    extended via the IANA registry defined and created in Section 8.        
  235    Some properties are defined at the global level; others are scoped to   
  236    apply only to a specific member zone.  This document defines a          
  237    mandatory global property in Section 4.2.1.  The "zones" label from     
  238    Section 4.1 can also be seen as a global property and is listed as      
  239    such in the IANA registry in Section 8.  Member-specific properties     
  240    are described in Section 4.3.                                           
  242    Implementers may store additional information in the catalog zone       
  243    with custom properties; see Section 4.4.  The meaning of such custom    
  244    properties is determined by the implementation in question.             
  246 4.2.1.  Schema Version (version property)                                  
  248    The catalog zone schema version is specified by an integer value        
  249    embedded in a TXT RR named version.$CATZ.  All catalog zones MUST       
  250    have a TXT RRset named version.$CATZ with exactly one RR.               
  252    Catalog consumers MUST NOT apply catalog zone processing to:            
  254    *  zones without the version property                                   
  256    *  zones with a version property with more than one RR in the RRset     
  258    *  zones with a version property without an expected value in the       
  259       version.$CATZ TXT RR                                                 
  261    *  zones with a version property with a schema version value that is    
  262       not implemented by the consumer (e.g., version "1")                  
  264    These conditions signify a broken catalog zone, which MUST NOT be       
  265    processed (see Section 5.1).                                            
  267    For this memo, the value of the version.$CATZ TXT RR MUST be set to     
  268    "2"; that is:                                                           
  270    version.$CATZ 0 IN TXT "2"                                              
  272    Note that Version 1 was used in an earlier draft version of this memo   
  273    and reflected the implementation first found in BIND 9.11.              
  275 4.3.  Member Zone Properties                                               
  277    Each member zone MAY have one or more additional properties that are    
  278    described in this section.  The member properties described in this     
  279    document are all optional, and implementations MAY choose to            
  280    implement all, some, or none of them.  Member zone properties are       
  281    represented by RRsets below the corresponding member node.              
  283 4.3.1.  Change of Ownership (coo property)                                 
  285    The coo property facilitates controlled migration of a member zone      
  286    from one catalog to another.                                            
  288    A Change Of Ownership is signaled by the coo property in the catalog    
  289    zone currently "owning" the zone.  The name of the new catalog is the   
  290    value of a PTR record in the relevant coo property in the old           
  291    catalog.  For example, if member "example.com." migrates from catalog   
  292    zone $OLDCATZ to catalog zone $NEWCATZ, this will appear in the         
  293    $OLDCATZ catalog zone as follows:                                       
  295    <unique-N>.zones.$OLDCATZ 0 IN PTR example.com.                         
  296    coo.<unique-N>.zones.$OLDCATZ 0 IN PTR $NEWCATZ                         
  298    The PTR RRset MUST consist of a single PTR record.  The presence of     
  299    more than one record in the RRset indicates a broken catalog zone,      
  300    which MUST NOT be processed (see Section 5.1).                          
  302    When a consumer of a catalog zone $OLDCATZ receives an update that      
  303    adds or changes a coo property for a member zone in $OLDCATZ, it does   
  304    _not_ migrate the member zone immediately.  The migration has to wait   
  305    for an update of $NEWCATZ in which the member zone is present.          
  306    Before the actual migration, the consumer MUST verify that the coo      
  307    property pointing to $NEWCATZ is still present in $OLDCATZ.             
  309    Unless the member node label (i.e., <unique-N>) for the member is the   
  310    same in $NEWCATZ, all its associated state for a just migrated zone     
  311    MUST be reset (see Section 5.6).  Note that the owner of $OLDCATZ       
  312    allows for the zone-associated state to be taken over by the owner of   
  313    $NEWCATZ by default.  To prevent the takeover of the zone-associated    
  314    state, the owner of $OLDCATZ must remove this state by updating the     
  315    associated properties or by performing a zone state reset (see          
  316    Section 5.6) before or simultaneous with adding the coo property (see   
  317    Section 7).                                                             
  319    The old owner may remove the member zone containing the coo property    
  320    from $OLDCATZ once it has been established that all its consumers       
  321    have processed the Change of Ownership.                                 
  323 4.3.2.  Groups (group property)                                            
  325    With a group property, a consumer(s) can be signaled to treat some      
  326    member zones within the catalog zone differently.                       
  328    The consumer MAY apply different configuration options when             
  329    processing member zones, based on the value of the group property.  A   
  330    group property value is stored as the entire RDATA of a TXT record      
  331    directly below the member node.  The exact handling of the group        
  332    property value is left to the consumer's implementation and             
  333    configuration.                                                          
  335    The producer MAY assign a group property to all, some, or none of the   
  336    member zones within a catalog zone.  The producer MAY assign more       
  337    than one group property to one member zone.  This will make it          
  338    possible to transfer group information for different consumer           
  339    operators in a single catalog zone.  Implementations MAY facilitate     
  340    mapping of a specific group value to a specific configuration           
  341    configurable _on a per catalog zone basis_ to allow for producers       
  342    that publish their catalog zone at multiple consumer operators.         
  343    Consumer operators SHOULD namespace their group values to reduce the    
  344    risk of having to resolve clashes.                                      
  346    The consumer MUST ignore group values it does not understand.  When a   
  347    consumer encounters multiple group values for a single member zone,     
  348    it MAY choose to process all, some, or none of them.  This is left to   
  349    the implementation.                                                     
  351  Example                                                          
  353    group properties are represented by TXT RRs.  The record content has    
  354    no pre-defined meaning.  Their interpretation is purely a matter of     
  355    agreement between the producer and the consumer(s) of the catalog.      
  357    For example, the "foo" group could be agreed to indicate that a zone    
  358    not be signed with DNSSEC.  Conversely, an agreement could define       
  359    that group names starting with "operator-" indicate in which way a      
  360    given DNS operator should set up certain aspects of the member zone's   
  361    DNSSEC configuration.                                                   
  363    Assuming that the catalog producer and consumer(s) have established     
  364    such agreements, consider the following catalog zone (snippet) that     
  365    signals to a consumer(s) how to treat DNSSEC for the zones              
  366    "example.net." and "example.com.":                                      
  368    <unique-1>.zones.$CATZ        0 IN PTR    example.com.                  
  369    group.<unique-1>.zones.$CATZ  0 IN TXT    "foo"                         
  370    <unique-2>.zones.$CATZ        0 IN PTR    example.net.                  
  371    group.<unique-2>.zones.$CATZ  0 IN TXT    "operator-x-foo"              
  372    group.<unique-2>.zones.$CATZ  0 IN TXT    "operator-y" "bar"            
  374    In this scenario, a consumer(s) shall, by agreement, not sign the       
  375    member zone "example.com." with DNSSEC.  For "example.net.", the        
  376    consumers, at two different operators, will configure the member zone   
  377    to be signed with a specific combination of settings.  The group        
  378    value designated to indicate this combination of settings is            
  379    prearranged with each operator ("operator-x-foo" vs. "operator-y"       
  380    "bar").                                                                 
  382 4.4.  Custom Properties (*.ext properties)                                 
  384    Implementations and operators of catalog zones may choose to provide    
  385    their own properties.  Custom properties can occur globally or for a    
  386    specific member zone.  To prevent a name clash with future              
  387    properties, such properties MUST be represented below the label         
  388    "ext".                                                                  
  390    "ext" is not a placeholder.  A custom property is named as follows:     
  392    ; a global custom property:                                             
  393    <property-prefix>.ext.$CATZ                                             
  395    ; a member zone custom property:                                        
  396    <property-prefix>.ext.<unique-N>.zones.$CATZ                            
  398    <property-prefix> may consist of one or more labels.                    
  400    Implementations SHOULD namespace their custom properties to limit       
  401    risk of clashes with other implementations of catalog zones.  This      
  402    can be achieved by using two labels as the <property-prefix> so that    
  403    the name of the implementation is included in the prefix: <some-        
  404    setting>.<implementation-name>.ext.$CATZ.                               
  406    Implementations MAY use such properties on the member zone level to     
  407    store additional information about member zones (e.g., to flag them     
  408    for specific treatment).                                                
  410    Further, implementations MAY use custom properties on the global        
  411    level to store additional information about the catalog zone itself.    
  412    While there may be many use cases for this, a plausible one is to       
  413    store default values for custom properties on the global level, then    
  414    override them using a property of the same name on the member level     
  415    (= under the ext label of the member node) if so desired.  A property   
  416    agreement between producer and consumer should clearly define what      
  417    semantics apply and whether a property is global, member, or both.      
  419    The meaning of the custom properties described in this section is       
  420    determined by the implementation alone without expectation of           
  421    interoperability.                                                       
  423 5.  Name Server Behavior                                                   
  425 5.1.  General Requirements                                                 
  427    As it is a regular DNS zone, a catalog zone can be transferred using    
  428    DNS zone transfers among name servers.                                  
  430    Catalog updates should be automatic; i.e., when a name server that      
  431    supports catalog zones completes a zone transfer for a catalog zone,    
  432    it SHOULD apply changes to the catalog within the running name server   
  433    automatically without any manual intervention.                          
  435    Name servers MAY allow loading and transfer of broken zones with        
  436    incorrect catalog zone syntax (as they are treated as regular zones).   
  437    The reason a catalog zone is considered broken SHOULD be communicated   
  438    clearly to the operator (e.g., through a log message).                  
  440    When a previously correct catalog zone becomes a broken catalog zone,   
  441    it loses its catalog meaning because of an update through an            
  442    incremental transfer or otherwise.  No special processing occurs.       
  443    Member zones previously configured by this catalog MUST NOT be          
  444    removed or reconfigured in any way.                                     
  446    If a name server restarts with a broken catalog zone, the broken        
  447    catalog SHOULD NOT prevent the name server from starting up and         
  448    serving the member zones in the last valid version of the catalog       
  449    zone.                                                                   
  451    Processing of a broken catalog SHALL start (or resume) when the         
  452    catalog turns into a correct catalog zone, e.g., by an additional       
  453    update (through zone transfer or updates) fixing the catalog zone.      
  455    Similarly, when a catalog zone expires, it loses its catalog meaning    
  456    and MUST no longer be processed as such.  No special processing         
  457    occurs until the zone becomes fresh again.                              
  459 5.2.  Member Zone Name Clash                                               
  461    If there is a clash between an existing zone's name (from either an     
  462    existing member zone or an otherwise configured zone) and an incoming   
  463    member zone's name (via transfer or update), the new instance of the    
  464    zone MUST be ignored and an error SHOULD be logged.                     
  466    A clash between an existing member zone's name and an incoming member   
  467    zone's name (via transfer or update) may be an attempt to migrate a     
  468    zone to a different catalog, but it should not be treated as one        
  469    except as described in Section 4.3.1.                                   
  471 5.3.  Member Zone Removal                                                  
  473    When a member zone is removed from a specific catalog zone, a           
  474    consumer MUST NOT remove the zone and associated state data if the      
  475    zone was not configured from that specific catalog zone.  The zone      
  476    and associated state (such as zone data and DNSSEC keys) MUST be        
  477    removed from the consumer when and only when the zone was configured    
  478    initially from the same catalog.  Consumer operators may consider       
  479    temporarily archiving associated state to facilitate mistake            
  480    recovery.                                                               
  482 5.4.  Member Node Name Change                                              
  484    When the member node's label value (<unique-N>) changes via a single    
  485    update or transfer, catalog consumers MUST process this as a member     
  486    zone removal, including the removal of all the zone's associated        
  487    state (as described in Section 5.3), and then immediately process the   
  488    member as a newly added zone to be configured in the same catalog.      
  490 5.5.  Migrating Member Zones between Catalogs                              
  492    If all consumers of the catalog zones involved support the coo          
  493    property, it is RECOMMENDED to perform migration of a member zone by    
  494    following the procedure described in Section 4.3.1.  Otherwise, the     
  495    migration of a member zone from a catalog zone $OLDCATZ to a catalog    
  496    zone $NEWCATZ has to be done by first removing the member zone from     
  497    $OLDCATZ and then adding the member zone to $NEWCATZ.                   
  499    If in the process of a migration some consumers of the involved         
  500    catalog zones did not catch the removal of the member zone from         
  501    $OLDCATZ yet (because of a lost packet or downtime or otherwise) but    
  502    already saw the update of $NEWCATZ containing the addition of that      
  503    member zone, they may consider this update to be a name clash (see      
  504    Section 5.2) and, as a consequence, the member is not migrated to       
  505    $NEWCATZ.  This possibility needs to be anticipated with a member       
  506    zone migration.  Recovery from such a situation is out of the scope     
  507    of this document.  For example, it may entail a manually forced         
  508    retransfer of $NEWCATZ to consumers after they have been detected to    
  509    have received and processed the removal of the member zone from         
  510    $OLDCATZ.                                                               
  512 5.6.  Zone-Associated State Reset                                          
  514    It may be desirable to reset state (such as zone data and DNSSEC        
  515    keys) associated with a member zone.                                    
  517    A zone state reset may be performed by a change of the member node's    
  518    name (see Section 5.4).                                                 
  520 6.  Implementation and Operational Notes                                   
  522    Although any valid domain name can be used for the catalog name         
  523    $CATZ, a catalog producer MUST NOT use names that are not under the     
  524    control of the catalog producer (with the exception of reserved         
  525    names).  It is RECOMMENDED to use either a domain name owned by the     
  526    catalog producer or a domain name under a suitable name such as         
  527    "invalid."  [RFC6761].                                                  
  529    Catalog zones on secondary name servers would have to be set up         
  530    manually, perhaps as static configuration, similar to how ordinary      
  531    DNS zones are configured when catalog zones or another automatic        
  532    configuration mechanism are not in place.  Additionally, the            
  533    secondary needs to be configured as a catalog consumer for the          
  534    catalog zone to enable processing of the member zones in the catalog,   
  535    such as automatic synchronization of the member zones for secondary     
  536    service.                                                                
  538    Operators of catalog consumers should note that secondary name          
  539    servers may receive DNS NOTIFY messages [RFC1996] for zones before      
  540    they are seen as newly added member zones to the catalog from which     
  541    that secondary is provisioned.                                          
  543    Although they are regular DNS zones, catalog zones only contain         
  544    information for the management of a set of authoritative name           
  545    servers.  To prevent unintended exposure to other parties, operators    
  546    SHOULD limit the systems able to query these zones.                     
  548    Querying/serving catalog zone contents may be inconvenient via DNS      
  549    due to the nature of their representation.  Therefore, an               
  550    administrator may want to use a different method for looking at data    
  551    inside the catalog zone.  Typical queries might include dumping the     
  552    list of member zones, dumping a member zone's effective                 
  553    configuration, querying a specific property value of a member zone,     
  554    etc.  Because of the structure of catalog zones, it may not be          
  555    possible to perform these queries intuitively, or in some cases at      
  556    all, using DNS QUERY.  For example, it is not possible to enumerate     
  557    the contents of a multivalued property (such as the list of member      
  558    zones) with a single QUERY.  Implementations are therefore advised to   
  559    provide a tool that uses either the output of AXFR or an out-of-band    
  560    method to perform queries on catalog zones.                             
  562    Great power comes with great responsibility.  Catalog zones simplify    
  563    zone provisioning by orchestrating zones on secondary name servers      
  564    from a single data source: the catalog.  Hence, the catalog producer    
  565    has great power and changes must be treated carefully.  For example,    
  566    if the catalog is generated by some script and this script generates    
  567    an empty catalog, millions of member zones may get deleted from their   
  568    secondaries within seconds, and all the affected domains may be         
  569    offline in a blink of an eye.                                           
  571 7.  Security Considerations                                                
  573    As catalog zones are transmitted using DNS zone transfers, it is        
  574    RECOMMENDED that catalog zone transfers be protected from unexpected    
  575    modifications by way of authentication, e.g., by using a Transaction    
  576    Signature (TSIG) [RFC8945] or Strict or Mutual TLS authentication       
  577    with DNS zone transfer over TLS or QUIC [RFC9103].                      
  579    Use of DNS UPDATE [RFC2136] to modify the content of catalog zones      
  580    SHOULD similarly be authenticated.                                      
  582    Zone transfers of member zones SHOULD similarly be authenticated.       
  583    TSIG shared secrets used for member zones SHOULD NOT be mentioned in    
  584    the catalog zone data.  However, key identifiers may be shared within   
  585    catalog zones.                                                          
  587    Catalog zones reveal the zones served by their consumers, including     
  588    their properties.  To prevent unintentional exposure of catalog zone    
  589    contents, it is RECOMMENDED to limit the systems able to query them     
  590    and to conduct catalog zone transfers confidentially [RFC9103].         
  592    As with regular zones, primary and secondary name servers for a         
  593    catalog zone may be operated by different administrators.  The          
  594    secondary name servers may be configured as a catalog consumer to       
  595    synchronize catalog zones from the primary, but the primary's           
  596    administrators may not have any administrative access to the            
  597    secondaries.                                                            
  599    Administrative control over what zones are served from the configured   
  600    name servers shifts completely from the server operator (consumer) to   
  601    the "owner" (producer) of the catalog zone content.  To prevent         
  602    unintended provisioning of zones, a consumer(s) SHOULD scope the set    
  603    of admissible member zones by any means deemed suitable (such as        
  604    statically via regular expressions, or dynamically by verifying         
  605    against another database before accepting a member zone).               
  607    With migration of member zones between catalogs using the coo           
  608    property, it is possible for the owner of the target catalog (i.e.,     
  609    $NEWCATZ) to take over all its associated state with the zone from      
  610    the original owner (i.e., $OLDCATZ) by maintaining the same member      
  611    node label (i.e., <unique-N>).  To prevent the takeover of the zone-    
  612    associated state, the original owner has to enforce a zone state        
  613    reset by changing the member node label (see Section 5.6) before or     
  614    simultaneously with adding the coo property.                            
  616 8.  IANA Considerations                                                    
  618    IANA has created the "DNS Catalog Zones Properties" registry under      
  619    the "Domain Name System (DNS) Parameters" registry as follows:          
  621    Registry Name:  DNS Catalog Zones Properties                            
  623    Assignment Policy:  Expert Review, except for property prefixes         
  624       ending in the label "ext", which are for Private Use [RFC8126].      
  626    Reference:  RFC 9432                                                    
  628    Note:  This registry applies to Catalog Zones schema version "2" as     
  629       specified in RFC 9432.                                               
  631     +=================+======================+===========+===========+     
  632     | Property Prefix | Description          | Status    | Reference |     
  633     +=================+======================+===========+===========+     
  634     | zones           | List of member zones | Standards | RFC 9432  |     
  635     |                 |                      | Track     |           |     
  636     +-----------------+----------------------+-----------+-----------+     
  637     | version         | Schema version       | Standards | RFC 9432  |     
  638     |                 |                      | Track     |           |     
  639     +-----------------+----------------------+-----------+-----------+     
  640     | coo             | Change of Ownership  | Standards | RFC 9432  |     
  641     |                 |                      | Track     |           |     
  642     +-----------------+----------------------+-----------+-----------+     
  643     | group           | Group                | Standards | RFC 9432  |     
  644     |                 |                      | Track     |           |     
  645     +-----------------+----------------------+-----------+-----------+     
  646     | *.ext           | Custom properties    | Private   | RFC 9432  |     
  647     |                 |                      | Use       |           |     
  648     +-----------------+----------------------+-----------+-----------+     
  650               Table 1: DNS Catalog Zones Properties Registry               
  652    The meanings of the fields are as follows:                              
  654    Property prefix:  One or more domain name labels.                       
  656    Description:  A human-readable short description or name for the        
  657       property.                                                            
  659    Status:  IETF Stream RFC status or "External" if not documented in an   
  660       IETF Stream RFC.                                                     
  662    Reference:  A stable reference to the document in which this property   
  663       is defined.                                                          
  665 9.  References                                                             
  667 9.1.  Normative References                                                 
  669    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  670               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  671               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  673    [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,   
  674               DOI 10.17487/RFC1982, August 1996,                           
  675               <https://www.rfc-editor.org/info/rfc1982>.                   
  677    [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone      
  678               Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,       
  679               August 1996, <https://www.rfc-editor.org/info/rfc1996>.      
  681    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  682               Requirement Levels", BCP 14, RFC 2119,                       
  683               DOI 10.17487/RFC2119, March 1997,                            
  684               <https://www.rfc-editor.org/info/rfc2119>.                   
  686    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,      
  687               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
  688               RFC 2136, DOI 10.17487/RFC2136, April 1997,                  
  689               <https://www.rfc-editor.org/info/rfc2136>.                   
  691    [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS      
  692               Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,   
  693               <https://www.rfc-editor.org/info/rfc2606>.                   
  695    [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",    
  696               RFC 6761, DOI 10.17487/RFC6761, February 2013,               
  697               <https://www.rfc-editor.org/info/rfc6761>.                   
  699    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  700               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  701               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  703    [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
  704               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
  705               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
  707    [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,         
  708               Gudmundsson, O., and B. Wellington, "Secret Key              
  709               Transaction Authentication for DNS (TSIG)", STD 93,          
  710               RFC 8945, DOI 10.17487/RFC8945, November 2020,               
  711               <https://www.rfc-editor.org/info/rfc8945>.                   
  713    [RFC9103]  Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.       
  714               Mankin, "DNS Zone Transfer over TLS", RFC 9103,              
  715               DOI 10.17487/RFC9103, August 2021,                           
  716               <https://www.rfc-editor.org/info/rfc9103>.                   
  718 9.2.  Informative References                                               
  720    [FOSDEM20] Vandewoestijne, L., "Extending Catalog zones - another       
  721               approach in automating maintenance", February 2020,          
  722               <https://archive.fosdem.org/2020/schedule/event/             
  723               dns_catz/>.                                                  
  725    [Metazones]                                                             
  726               Vixie, P., "Federated Domain Name Service Using DNS          
  727               Metazones", DOI 10.1093/ietcom/e89-b.4.1144, April 2006,     
  728               <https://www.semanticscholar.org/paper/Federated-Domain-     
  729               Name-Service-Using-DNS-Metazones-Vixie/                      
  730               dc12b0116332f5c236b05c71bbe20499f3c6c4b6>.                   
  732    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for        
  733               Writing an IANA Considerations Section in RFCs", BCP 26,     
  734               RFC 8126, DOI 10.17487/RFC8126, June 2017,                   
  735               <https://www.rfc-editor.org/info/rfc8126>.                   
  737 Appendix A.  Catalog Zone Example                                          
  739    The following is a full example of a catalog zone containing three      
  740    member zones with various properties:                                   
  742    catalog.invalid.                                0  SOA   invalid. (     
  743                            invalid. 1625079950 3600 600 2147483646 0 )     
  744    catalog.invalid.                                0  NS    invalid.       
  745    example.vendor.ext.catalog.invalid.             0  CNAME example.net.   
  746    version.catalog.invalid.                        0  TXT   "2"            
  747    nj2xg5b.zones.catalog.invalid.                  0  PTR   example.com.   
  748    nvxxezj.zones.catalog.invalid.                  0  PTR   example.net.   
  749    group.nvxxezj.zones.catalog.invalid.            0  TXT   (              
  750                            "operator-x-foo" )                              
  751    nfwxa33.zones.catalog.invalid.                  0  PTR   example.org.   
  752    coo.nfwxa33.zones.catalog.invalid.              0  PTR   (              
  753                            newcatz.invalid. )                              
  754    group.nfwxa33.zones.catalog.invalid.            0  TXT   (              
  755                            "operator-y-bar" )                              
  756    metrics.vendor.ext.nfwxa33.zones.catalog.invalid. 0  CNAME (            
  757                            collector.example.net. )                        
  759 Acknowledgements                                                           
  761    Our deepest thanks and appreciation go to Stephen Morris, Ray Bellis,   
  762    and Witold Krecicki who initiated this document and did the bulk of     
  763    the work.                                                               
  765    Catalog zones originated as the chosen method among various proposals   
  766    that were evaluated at Internet Systems Consortium (ISC) for easy       
  767    zone management.  The chosen method of storing the catalog as a         
  768    regular DNS zone was proposed by Stephen Morris.                        
  770    The initial authors discovered that Paul Vixie's earlier [Metazones]    
  771    proposal implemented a similar approach, and they reviewed it.          
  772    Catalog zones borrow some syntax ideas from [Metazones], as both        
  773    share this scheme of representing the catalog as a regular DNS zone.    
  775    Thanks to Leo Vandewoestijne.  Leo's presentation in the DNS devroom    
  776    at FOSDEM'20 [FOSDEM20] was one of the motivations to take up and       
  777    continue the effort of standardizing catalog zones.                     
  779    Thanks to Joe Abley, David Blacka, Brian Conry, Klaus Darilion, Brian   
  780    Dickson, Tony Finch, Evan Hunt, Shane Kerr, Warren Kumari, Patrik       
  781    Lundin, Matthijs Mekking, Victoria Risk, Josh Soref, Petr Spacek,       
  782    Michael StJohns, Carsten Strotmann, and Tim Wicinski for reviewing      
  783    earlier draft versions and offering comments and suggestions.           
  785 Authors' Addresses                                                         
  787    Peter van Dijk                                                          
  788    PowerDNS                                                                
  789    Den Haag                                                                
  790    Netherlands                                                             
  791    Email: peter.van.dijk@powerdns.com                                      
  794    Libor Peltan                                                            
  795    CZ.NIC                                                                  
  796    Czech Republic                                                          
  797    Email: libor.peltan@nic.cz                                              
  800    Ondrej Sury                                                             
  801    Internet Systems Consortium                                             
  802    Czech Republic                                                          
  803    Email: ondrej@isc.org                                                   
  806    Willem Toorop                                                           
  807    NLnet Labs                                                              
  808    Science Park 400                                                        
  809    1098 XH Amsterdam                                                       
  810    Netherlands                                                             
  811    Email: willem@nlnetlabs.nl                                              
  814    Kees Monshouwer                                                         
  815    Netherlands                                                             
  816    Email: mind@monshouwer.eu                                               
  819    Peter Thomassen                                                         
  820    deSEC, SSE - Secure Systems Engineering                                 
  821    Berlin                                                                  
  822    Germany                                                                 
  823    Email: peter@desec.io                                                   
  826    Aram Sargsyan                                                           
  827    Internet Systems Consortium                                             
  828    Email: aram@isc.org                                                     

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.