idnits 2.17.1 draft-ietf-dnsop-dns-catalog-zones-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: | Editorial nits from David Blacka, Lars Eggert, Russ Housley, Erik | Kline, É (U+00C9)ric Vyncke and Paul Wouters | | Addes a Catalog Zone Exampla | | Mention that the document uses DNS specific terminology and | reference RFC8499 | | Added IANA Considerations sections, with a registry for Catalog | Zones properties | | Updated Implementation status also with respect to Catalog zones | version "1" support | | 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) | | Change example group values in non descriptive names | | Add some more clarifications on that and how group values are | determined in producer/consumer agreements | | Stronger checking suggestion (SHOULD instead of MAY) in accepting | member zones by consumers in the Security section | | Added mistake recovery text to the Member zone removal section | | Replace vague language ("meaningless") with more precise wording | | Catalog consumers that know only version "2" MUST not process | version "1" catalog zones and consider it broken. | | The entire RDATA of a group property is it's value -- The document date (7 February 2023) is 445 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group P. van Dijk 3 Internet-Draft PowerDNS 4 Intended status: Standards Track L. Peltan 5 Expires: 11 August 2023 CZ.NIC 6 O. Sury 7 Internet Systems Consortium 8 W. Toorop 9 NLnet Labs 10 C.R. Monshouwer 12 P. Thomassen 13 deSEC, SSE - Secure Systems Engineering 14 A. Sargsyan 15 Internet Systems Consortium 16 7 February 2023 18 DNS Catalog Zones 19 draft-ietf-dnsop-dns-catalog-zones-09 21 Abstract 23 This document describes a method for automatic DNS zone provisioning 24 among DNS primary and secondary nameservers by storing and 25 transferring the catalog of zones to be provisioned as one or more 26 regular DNS zones. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 11 August 2023. 45 Copyright Notice 47 Copyright (c) 2023 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Catalog Zone Structure . . . . . . . . . . . . . . . . . . . 4 65 4.1. Member Zones . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2.1. Schema Version (version property) . . . . . . . . . . 6 68 4.3. Member Zone Properties . . . . . . . . . . . . . . . . . 7 69 4.3.1. Change of Ownership (coo property) . . . . . . . . . 7 70 4.3.2. Groups (group property) . . . . . . . . . . . . . . . 8 71 4.4. Custom Properties (*.ext properties) . . . . . . . . . . 9 72 5. Nameserver Behavior . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. General Requirements . . . . . . . . . . . . . . . . . . 10 74 5.2. Member zone name clash . . . . . . . . . . . . . . . . . 11 75 5.3. Member zone removal . . . . . . . . . . . . . . . . . . . 11 76 5.4. Member node name change . . . . . . . . . . . . . . . . . 11 77 5.5. Migrating member zones between catalogs . . . . . . . . . 11 78 5.6. Zone-associated state reset . . . . . . . . . . . . . . . 12 79 6. Implementation and Operational Notes . . . . . . . . . . . . 12 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 84 11. Informative References . . . . . . . . . . . . . . . . . . . 17 85 Appendix A. Catalog Zone Example . . . . . . . . . . . . . . . . 17 86 Appendix B. Implementation Status . . . . . . . . . . . . . . . 18 87 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 The content of a DNS zone is synchronized among its primary and 93 secondary nameservers using AXFR and IXFR. However, the list of 94 zones served by the primary (called a catalog in [RFC1035]) is not 95 automatically synchronized with the secondaries. To add or remove a 96 zone, the administrator of a DNS nameserver farm not only has to add 97 or remove the zone from the primary, they must also add/remove 98 configuration for the zone from all secondaries. This can be both 99 inconvenient and error-prone; in addition, the steps required are 100 dependent on the nameserver implementation. 102 This document describes a method in which the list of zones is 103 represented as a regular DNS zone (called a "catalog zone" here), and 104 transferred using DNS zone transfers. When entries are added to or 105 removed from the catalog zone, it is distributed to the secondary 106 nameservers just like any other zone. Secondary nameservers can then 107 add/remove/modify the zones they serve in accordance with the changes 108 to the catalog zone. Other use-cases of nameserver remote 109 configuration by catalog zones are possible, where the catalog 110 consumer might not be a secondary. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119][RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 Catalog zone: A DNS zone containing a DNS catalog, that is, a list 121 of DNS zones and associated properties. 123 Member zone: A DNS zone whose configuration is published inside a 124 catalog zone. 126 Member node: A DNS name in the Catalog zone representing a Member 127 zone. 129 $CATZ: Used in examples as a placeholder to represent the domain 130 name of the catalog zone itself. $OLDCATZ and $NEWCATZ are used to 131 discuss migration of a member zone from one catalog zone $OLDCATZ 132 to another catalog zone $NEWCATZ. 134 Catalog producer: An entity that generates and is responsible for 135 the contents of the catalog zone. 137 Catalog consumer: An entity that extracts information from the 138 catalog zone (such as a DNS server that configures itself 139 according to the catalog zone's contents). 141 This document makes use of terminology that is specific to the DNS, 142 such as for transfer mechanisms (AXFR, IXFR), for record types (SOA, 143 NS, PTR), and other technical terms (such as RDATA). Since these 144 terms have specific meanings in the DNS they are not expanded at 145 first use in this document. For definitions of those and other 146 terms, see [RFC8499]. 148 3. Description 150 A catalog zone is a DNS zone whose contents are specially crafted. 151 Its resource records (RR) primarily constitute a list of PTR records 152 referencing other DNS zones (so-called "member zones"). The catalog 153 zone may contain other records indicating additional metadata (so- 154 called "properties") associated with these member zones. 156 Catalog consumers MUST ignore any RRs in the catalog zone for which 157 no processing is specified or which are otherwise not supported by 158 the implementation. 160 Authoritative servers may be pre-configured with multiple catalog 161 zones, each associated with a different set of configurations. 163 Although the contents of a catalog zone are interpreted and acted 164 upon by nameservers, a catalog zone is a regular DNS zone and so must 165 adhere to the standards for DNS zones. 167 A catalog zone is primarily intended for the management of a farm of 168 authoritative nameservers, and should not be expected to be 169 accessible from any recursive nameserver. 171 4. Catalog Zone Structure 173 A catalog zone MUST follow the usual rules for DNS zones. In 174 particular, SOA and NS record sets MUST be present and adhere to 175 standard requirements (such as [RFC1982]). 177 Although catalog zones are not intended to be queried via recursive 178 resolution (see Section 7), at least one NS RR is still required so 179 that a catalog zone is a syntactically correct DNS zone. A single NS 180 RR with a NSDNAME field containing the absolute name "invalid." is 181 RECOMMENDED [RFC2606][RFC6761]. 183 4.1. Member Zones 185 The list of member zones is specified as a collection of member 186 nodes, represented by domain names under the owner name "zones" where 187 "zones" is a direct child domain of the catalog zone. 189 The names of member zones are represented on the RDATA side (instead 190 of as a part of owner names) of a PTR record, so that all valid 191 domain names may be represented regardless of their length [RFC1035]. 192 This PTR record MUST be the only record in the PTR RRset with the 193 same name. The presence of more than one record in the RRset 194 indicates a broken catalog zone which MUST NOT be processed (see 195 Section 5.1). 197 For example, if a catalog zone lists three zones "example.com.", 198 "example.net." and "example.org.", the member node RRs would appear 199 as follows: 201 .zones.$CATZ 0 IN PTR example.com. 202 .zones.$CATZ 0 IN PTR example.net. 203 .zones.$CATZ 0 IN PTR example.org. 205 where is a label that tags each record in the collection. 206 has a unique value in the collection. When different 207 labels hold the same PTR value (i.e., point to the same 208 member zone), the catalog zone is broken and MUST NOT be processed 209 (see Section 5.1). 211 Member node labels carry no informational meaning beyond labeling 212 member zones. A changed label may indicate that the state for a zone 213 needs to be reset (see Section 5.6). 215 Having the zones uniquely tagged with the label ensures 216 that additional RRs can be added below the member node (see 217 Section 4.2). 219 The CLASS field of every RR in a catalog zone MUST be IN (1). The 220 TTL field's value has no meaning in this context and SHOULD be 221 ignored. 223 4.2. Properties 225 Catalog zone information is stored in the form of "properties". 227 Properties are identified by their name, which is used as an owner 228 name prefix for one or more record sets underneath a member node (or 229 underneath the catalog zone apex), with RR type(s) as appropriate for 230 the respective property. 232 Known properties with the correct RR type, but which are for some 233 reason invalid (for example because of an impossible value or because 234 of an illegal number of RRs in the RRset), denote a broken catalog 235 zone which MUST NOT be processed (see Section 5.1). 237 This document includes a set of initial properties which can be 238 extended via the IANA registry defined and created in Section 8. 239 Some properties are defined at the global level; others are scoped to 240 apply only to a specific member zone. This document defines a 241 mandatory global property in Section 4.2.1. The "zones" label from 242 Section 4.1 can also be seen as a global property and is listed as 243 such in the IANA registry in Section 8. Member-specific properties 244 are described in Section 4.3. 246 Implementers may store additional information in the catalog zone 247 with Custom properties, see Section 4.4. The meaning of such custom 248 properties is determined by the implementation in question. 250 4.2.1. Schema Version (version property) 252 The catalog zone schema version is specified by an integer value 253 embedded in a TXT RR named version.$CATZ. All catalog zones MUST 254 have a TXT RRset named version.$CATZ with exactly one RR. 256 Catalog consumers MUST NOT apply catalog zone processing to 258 * zones without the version property 260 * zones with a version property with more than one RR in the RRset 262 * zones with a version property without an expected value in the 263 version.$CATZ TXT RR 265 * zones with a version property with a schema version value which is 266 not implemented by the consumer (e.g. version "1") 268 These conditions signify a broken catalog zone which MUST NOT be 269 processed (see Section 5.1). 271 For this memo, the value of the version.$CATZ TXT RR MUST be set to 272 "2", i.e.: 274 version.$CATZ 0 IN TXT "2" 276 NB: Version 1 was used in a draft version of this memo and reflected 277 the implementation first found in BIND 9.11. 279 4.3. Member Zone Properties 281 Each member zone MAY have one or more additional properties, 282 described in this chapter. The member properties described in this 283 document are all optional and implementations MAY choose to implement 284 all, some or none of them. Member zone properties are represented by 285 RRsets below the corresponding member node. 287 4.3.1. Change of Ownership (coo property) 289 The coo property facilitates controlled migration of a member zone 290 from one catalog to another. 292 A Change Of Ownership is signaled by the coo property in the catalog 293 zone currently "owning" the zone. The name of the new catalog is the 294 value of a PTR record in the relevant coo property in the old 295 catalog. For example if member "example.com." will migrate from 296 catalog zone $OLDCATZ to catalog zone $NEWCATZ, this appears in the 297 $OLDCATZ catalog zone as follows: 299 .zones.$OLDCATZ 0 IN PTR example.com. 300 coo..zones.$OLDCATZ 0 IN PTR $NEWCATZ 302 The PTR RRset MUST consist of a single PTR record. The presence of 303 more than one record in the RRset indicates a broken catalog zone 304 which MUST NOT be processed (see Section 5.1). 306 When a consumer of a catalog zone $OLDCATZ receives an update which 307 adds or changes a coo property for a member zone in $OLDCATZ, it does 308 _not_ migrate the member zone immediately. The migration has to wait 309 for an update of $NEWCATZ. in which the member zone is present. The 310 consumer MUST verify, before the actual migration, that coo property 311 pointing to $NEWCATZ is still present in $OLDCATZ. 313 Unless the member node label (i.e., ) for the member is the 314 same in $NEWCATZ, all its associated state for a just migrated zone 315 MUST be reset (see Section 5.6). Note that the owner of $OLDCATZ 316 allows for the zone associated state to be taken over by the owner of 317 $NEWCATZ by default. To prevent the takeover of state, the owner of 318 $OLDCATZ must remove this state by updating the associated properties 319 or by performing a zone state reset (see Section 5.6) before or 320 simultaneous with adding the coo property. (see also Section 7) 322 The old owner may remove the member zone containing the coo property 323 from $OLDCATZ once it has been established that all its consumers 324 have processed the Change of Ownership. 326 4.3.2. Groups (group property) 328 With a group property, consumer(s) can be signaled to treat some 329 member zones within the catalog zone differently. 331 The consumer MAY apply different configuration options when 332 processing member zones, based on the value of the group property. A 333 group property value is stored as the entire RDATA of a TXT record 334 directly below the member node. The exact handling of the group 335 property value is left to the consumer's implementation and 336 configuration. 338 The producer MAY assign a group property to all, some, or none of the 339 member zones within a catalog zone. The producer MAY assign more 340 than one group property to one member zone. This will make it 341 possible to transfer group information for different consumer 342 operators in a single catalog zone. Implementations MAY facilitate 343 mapping of a specific group value to specific configuration 344 configurable _on a per catalog zone basis_ to allow for producers 345 that publish their catalog zone at multiple consumer operators. 346 Consumer operators SHOULD namespace their group values to reduce the 347 risk of having to resolve clashes. 349 The consumer MUST ignore group values it does not understand. When a 350 consumer encounters multiple group values for a single member zone, 351 it MAY choose to process all, some or none of them. This is left to 352 the implementation. 354 4.3.2.1. Example 356 Group properties are represented by TXT resource records. The record 357 content has no pre-defined meaning. Their interpretation is purely a 358 matter of agreement between the producer and the consumer(s) of the 359 catalog. 361 For example, the "foo" group could be agreed to indicate that a zone 362 not be signed with DNSSEC. Conversely, an agreement could define 363 that group names starting with "operator-" indicate in which way a 364 given DNS operator should set up certain aspects of the member zone's 365 DNSSEC configuration. 367 Assuming that the catalog producer and consumer(s) have established 368 such agreements, consider the following catalog zone (snippet) which 369 signals to consumer(s) how to treat DNSSEC for the zones 370 "example.net." and "example.com.": 372 .zones.$CATZ 0 IN PTR example.com. 373 group..zones.$CATZ 0 IN TXT "foo" 374 .zones.$CATZ 0 IN PTR example.net. 375 group..zones.$CATZ 0 IN TXT "operator-x-foo" 376 group..zones.$CATZ 0 IN TXT "operator-y" "bar" 378 In this scenario, consumer(s) shall, by agreement, not sign the 379 member zone "example.com." with DNSSEC. For "example.net.", the 380 consumers, at two different operators, will configure the member zone 381 to be signed with a specific combination of settings. The group 382 value that indicates that depends on what has been agreed with each 383 operator ("operator-x-foo" vs. "operator-y" "bar"). 385 4.4. Custom Properties (*.ext properties) 387 Implementations and operators of catalog zones may choose to provide 388 their own properties. Custom properties can occur both globally, or 389 for a specific member zone. To prevent a name clash with future 390 properties, such properties MUST be represented below the label 391 "ext". 393 "ext" is not a placeholder. A custom property is named as follows: 395 ; a global custom property: 396 .ext.$CATZ 398 ; a member zone custom property: 399 .ext..zones.$CATZ 401 may consist of one or more labels. 403 Implementations SHOULD namespace their custom properties to limit 404 risk of clashes with other implementations of catalog zones. This 405 can be achieved by using two labels as the , so that 406 the name of the implementation is included in the prefix: ..ext.$CATZ. 409 Implementations MAY use such properties on the member zone level to 410 store additional information about member zones, for example to flag 411 them for specific treatment. 413 Further, implementations MAY use custom properties on the global 414 level to store additional information about the catalog zone itself. 415 While there may be many use cases for this, a plausible one is to 416 store default values for custom properties on the global level, then 417 overriding them using a property of the same name on the member level 418 (= under the ext label of the member node) if so desired. A property 419 agreement between producer and consumer should clearly define what 420 semantics apply, and whether a property is global, member, or both. 422 The meaning of the custom properties described in this section is 423 determined by the implementation alone, without expectation of 424 interoperability. 426 5. Nameserver Behavior 428 5.1. General Requirements 430 As it is a regular DNS zone, a catalog zone can be transferred using 431 DNS zone transfers among nameservers. 433 Catalog updates should be automatic, i.e., when a nameserver that 434 supports catalog zones completes a zone transfer for a catalog zone, 435 it SHOULD apply changes to the catalog within the running nameserver 436 automatically without any manual intervention. 438 Nameservers MAY allow loading and transfer of broken zones with 439 incorrect catalog zone syntax (as they are treated as regular zones). 440 The reason a catalog zone is considered broken SHOULD be communicated 441 clearly to the operator (e.g. through a log message). 443 When a previously correct catalog zone becomes a broken catalog zone, 444 because of an update through an incremental transfer or otherwise, it 445 loses its catalog meaning. No special processing occurs. Member 446 zones previously configured by this catalog MUST NOT be removed or 447 reconfigured in any way. 449 If a name server restarts with a broken catalog zone, the broken 450 catalog SHOULD NOT prevent the name server from starting up and 451 serving the member zones in the last valid version of the catalog 452 zone. 454 Processing of a broken catalog SHALL start (or resume) when the 455 catalog turns into a correct catalog zone, for example by an 456 additional update (through zone transfer or updates) fixing the 457 catalog zone. 459 Similarly, when a catalog zone expires, it loses its catalog meaning 460 and MUST no longer be processed as such. No special processing 461 occurs until the zone becomes fresh again. 463 5.2. Member zone name clash 465 If there is a clash between an existing zone's name (either from an 466 existing member zone or otherwise configured zone) and an incoming 467 member zone's name (via transfer or update), the new instance of the 468 zone MUST be ignored and an error SHOULD be logged. 470 A clash between an existing member zone's name and an incoming member 471 zone's name (via transfer or update), may be an attempt to migrate a 472 zone to a different catalog, but should not be treated as one except 473 as described in Section 4.3.1. 475 5.3. Member zone removal 477 When a member zone is removed from a specific catalog zone, a 478 consumer MUST NOT remove the zone and associated state data if the 479 zone was not configured from that specific catalog zone. Only when 480 the zone was configured from a specific catalog zone, and the zone is 481 removed as a member from that specific catalog zone, the zone and 482 associated state (such as zone data and DNSSEC keys) MUST be removed 483 from the consumer. Consumer operators may consider to temporarily 484 archive associated state to facilitate mistake recovery. 486 5.4. Member node name change 488 When via a single update or transfer, the member node's label value 489 () changes, catalog consumers MUST process this as a member 490 zone removal including all the zone's associated state (as described 491 in Section 5.3), immediately followed by processing the member as a 492 newly to be configured zone in the same catalog. 494 5.5. Migrating member zones between catalogs 496 If all consumers of the catalog zones involved support the coo 497 property, it is RECOMMENDED to perform migration of a member zone by 498 following the procedure described in Section 4.3.1. Otherwise, a 499 migration of a member zone from a catalog zone $OLDCATZ to a catalog 500 zone $NEWCATZ has to be done by: first removing the member zone from 501 $OLDCATZ; second adding the member zone to $NEWCATZ. 503 If in the process of a migration some consumers of the involved 504 catalog zones did not catch the removal of the member zone from 505 $OLDCATZ yet (because of a lost packet or downtime or otherwise), but 506 did already see the update of $NEWCATZ, they may consider the update 507 adding the member zone in $NEWCATZ to be a name clash (see 508 Section 5.2) and as a consequence the member is not migrated to 509 $NEWCATZ. This possibility needs to be anticipated with a member 510 zone migration. Recovery from such a situation is out of the scope 511 of this document. It may for example entail a manually forced 512 retransfer of $NEWCATZ to consumers after they have been detected to 513 have received and processed the removal of the member zone from 514 $OLDCATZ. 516 5.6. Zone-associated state reset 518 It may be desirable to reset state (such as zone data and DNSSEC 519 keys) associated with a member zone. 521 A zone state reset may be performed by a change of the member node's 522 name (see Section 5.4). 524 6. Implementation and Operational Notes 526 Although any valid domain name can be used for the catalog name 527 $CATZ, a catalog producer MUST NOT use names that are not under the 528 control of the catalog producer (with the exception of reserved 529 names). It is RECOMMENDED to use either a domain name owned by the 530 catalog producer, or to use a name under a suitable name such as 531 "invalid." [RFC6761]. 533 Catalog zones on secondary nameservers would have to be set up 534 manually, perhaps as static configuration, similar to how ordinary 535 DNS zones are configured when catalog zones or another automatic 536 configuration mechanism are not in place. The secondary additionally 537 needs to be configured as a catalog consumer for the catalog zone to 538 enable processing of the member zones in the catalog, such as 539 automatic synchronization of the member zones for secondary service. 541 Operators of catalog consumers should note that secondary name 542 servers may receive DNS NOTIFY messages [RFC1996] for zones before 543 they are seen as newly added member zones to the catalog from which 544 that secondary is provisioned. 546 Although they are regular DNS zones, catalog zones contain only 547 information for the management of a set of authoritative nameservers. 548 To prevent unintended exposure to other parties, operators SHOULD 549 limit the systems able to query these zones. 551 Querying/serving catalog zone contents may be inconvenient via DNS 552 due to the nature of their representation. An administrator may 553 therefore want to use a different method for looking at data inside 554 the catalog zone. Typical queries might include dumping the list of 555 member zones, dumping a member zone's effective configuration, 556 querying a specific property value of a member zone, etc. Because of 557 the structure of catalog zones, it may not be possible to perform 558 these queries intuitively, or in some cases, at all, using DNS QUERY. 559 For example, it is not possible to enumerate the contents of a 560 multivalued property (such as the list of member zones) with a single 561 QUERY. Implementations are therefore advised to provide a tool that 562 uses either the output of AXFR or an out-of-band method to perform 563 queries on catalog zones. 565 Great power comes with great responsibility: Catalog zones simplify 566 zone provisioning by orchestrating zones on secondary name servers 567 from a single data source - the catalog. Hence, the catalog producer 568 has great power and changes must be treated carefully. For example 569 if the catalog is generated by some script and this script for 570 whatever reason generates an empty catalog, millions of member zones 571 may get deleted from their secondaries within seconds and all the 572 affected domains may be offline in a blink of an eye. 574 7. Security Considerations 576 As catalog zones are transmitted using DNS zone transfers, it is 577 RECOMMENDED that catalog zone transfers are protected from unexpected 578 modifications by way of authentication, for example by using TSIG 579 [RFC8945], or Strict or Mutual TLS authentication with DNS Zone 580 transfer over TLS or QUIC [RFC9103]. 582 Use of DNS UPDATE [RFC2136] to modify the content of catalog zones 583 SHOULD similarly be authenticated. 585 Zone transfers of member zones SHOULD similarly be authenticated. 586 TSIG shared secrets used for member zones SHOULD NOT be mentioned in 587 the catalog zone data. However, key identifiers may be shared within 588 catalog zones. 590 Catalog zones reveal the zones served by their consumers, including 591 their properties. To prevent unintentional exposure of catalog zone 592 contents, it is RECOMMENDED to limit the systems able to query them 593 and to conduct catalog zone transfers confidentially [RFC9103]. 595 As with regular zones, primary and secondary nameservers for a 596 catalog zone may be operated by different administrators. The 597 secondary nameservers may be configured as a catalog consumer to 598 synchronize catalog zones from the primary, but the primary's 599 administrators may not have any administrative access to the 600 secondaries. 602 Administrative control over what zones are served from the configured 603 name servers shifts completely from the server operator (consumer) to 604 the "owner" (producer) of the catalog zone content. To prevent 605 unintended provisioning of zones, consumer(s) SHOULD scope the set of 606 admissible member zones by any means deemed suitable (such as 607 statically, via regular expressions, or dynamically, by verifying 608 against another database before accepting a member zone). 610 With migration of member zones between catalogs using the coo 611 property, it is possible for the owner of the target catalog (i.e., 612 $NEWCATZ) to take over all its associated state with the zone from 613 the original owner (i.e., $OLDCATZ) by maintaining the same member 614 node label (i.e., ). To prevent the takeover of the zone 615 associated state, the original owner has to enforce a zone state 616 reset by changing the member node label (see Section 5.6) before or 617 simultaneously with adding the coo property. 619 8. IANA Considerations 621 IANA is requested to create a registry on the "Domain Name System 622 (DNS) Parameters" IANA web page as follows: 624 Registry Name: DNS Catalog Zones Properties 626 Assignment Policy: Expert Review, except for property prefixes 627 ending in the label "ext", which are for Private Use. 629 Reference: [this document] 631 Note: This registry does not apply to Catalog Zones version "1", but 632 applies to Catalog Zones version "2" as specified in [this 633 document]. 635 +=================+======================+===========+===========+ 636 | Property prefix | Description | Status | Reference | 637 +=================+======================+===========+===========+ 638 | zones | List of member zones | Standards | [this | 639 | | | Track | document] | 640 +-----------------+----------------------+-----------+-----------+ 641 | version | Schema version | Standards | [this | 642 | | | Track | document] | 643 +-----------------+----------------------+-----------+-----------+ 644 | coo | Change of Ownership | Standards | [this | 645 | | | Track | document] | 646 +-----------------+----------------------+-----------+-----------+ 647 | group | Group | Standards | [this | 648 | | | Track | document] | 649 +-----------------+----------------------+-----------+-----------+ 650 | *.ext | Custom properties | Private | [this | 651 | | | Use | document] | 652 +-----------------+----------------------+-----------+-----------+ 654 Table 1 656 The meanings of the fields are as follows: 658 Property prefix: One or more domain name labels 660 Description: A human readable short description or name for the 661 property 663 Status: IETF Document status or "External" if not documented in an 664 IETF document. 666 Reference: A stable reference to the document in which this property 667 is defined. 669 9. Acknowledgements 671 Our deepest thanks and appreciation go to Stephen Morris, Ray Bellis 672 and Witold Krecicki who initiated this draft and did the bulk of the 673 work. 675 Catalog zones originated as the chosen method among various proposals 676 that were evaluated at ISC for easy zone management. The chosen 677 method of storing the catalog as a regular DNS zone was proposed by 678 Stephen Morris. 680 The initial authors discovered that Paul Vixie's earlier [Metazones] 681 proposal implemented a similar approach and reviewed it. Catalog 682 zones borrow some syntax ideas from Metazones, as both share this 683 scheme of representing the catalog as a regular DNS zone. 685 Thanks to Leo Vandewoestijne. Leo's presentation in the DNS devroom 686 at the FOSDEM'20 [FOSDEM20] was one of the motivations to take up and 687 continue the effort of standardizing catalog zones. 689 Thanks to Joe Abley, David Blacka, Brian Conry, Klaus Darilion, Brian 690 Dickson, Tony Finch, Evan Hunt, Shane Kerr, Warren Kumari, Patrik 691 Lundin, Matthijs Mekking, Victoria Risk, Josh Soref, Petr Spacek, 692 Michael StJohns, Carsten Strotmann and Tim Wicinski for reviewing 693 draft proposals and offering comments and suggestions. 695 10. Normative References 697 [RFC1035] Mockapetris, P., "Domain names - implementation and 698 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 699 November 1987, . 701 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 702 DOI 10.17487/RFC1982, August 1996, 703 . 705 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 706 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 707 August 1996, . 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, 711 DOI 10.17487/RFC2119, March 1997, 712 . 714 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 715 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 716 RFC 2136, DOI 10.17487/RFC2136, April 1997, 717 . 719 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 720 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 721 . 723 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 724 RFC 6761, DOI 10.17487/RFC6761, February 2013, 725 . 727 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 728 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 729 May 2017, . 731 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 732 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 733 January 2019, . 735 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., 736 Gudmundsson, O., and B. Wellington, "Secret Key 737 Transaction Authentication for DNS (TSIG)", STD 93, 738 RFC 8945, DOI 10.17487/RFC8945, November 2020, 739 . 741 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. 742 Mankin, "DNS Zone Transfer over TLS", RFC 9103, 743 DOI 10.17487/RFC9103, August 2021, 744 . 746 11. Informative References 748 [FOSDEM20] Vandewoestijne, L., "Extending Catalog zones - another 749 approach in automating maintenance", 2020, 750 . 753 [Metazones] 754 Vixie, P., "Federated Domain Name Service Using DNS 755 Metazones", 2005, 756 . 758 Appendix A. Catalog Zone Example 760 The following is a full example of a catalog zone containing three 761 member zones with various properties: 763 catalog.invalid. 0 SOA invalid. ( 764 invalid. 1625079950 3600 600 2147483646 0 ) 765 catalog.invalid. 0 NS invalid. 766 example.vendor.ext.catalog.invalid. 0 CNAME example.net. 767 version.catalog.invalid. 0 TXT "2" 768 nj2xg5b.zones.catalog.invalid. 0 PTR example.com. 769 nvxxezj.zones.catalog.invalid. 0 PTR example.net. 770 group.nvxxezj.zones.catalog.invalid. 0 TXT ( 771 "operator-x-foo" ) 772 nfwxa33.zones.catalog.invalid. 0 PTR example.org. 773 coo.nfwxa33.zones.catalog.invalid. 0 PTR ( 774 newcatz.invalid. ) 775 group.nfwxa33.zones.catalog.invalid. 0 TXT ( 776 "operator-y-bar" ) 777 metrics.vendor.ext.nfwxa33.zones.catalog.invalid. 0 CNAME ( 778 collector.example.net. ) 780 Appendix B. Implementation Status 782 *Note to the RFC Editor*: please remove this entire appendix before 783 publication. 785 In the following implementation status descriptions, "DNS Catalog 786 Zones" refers to DNS Catalog Zones version 2 as described in this 787 document. Version 1 of catalog zones was initially developed by ISC 788 for BIND, but never standardized in the IETF. Support for version 1 789 catalog zones is explicitly mentioned per implementation. Support 790 for the coo and group properties are also explicitly mentioned per 791 implementation. 793 * Knot DNS 3.1 (released August 2, 2021) supports both producing and 794 consuming of catalog zones, including the group property. 796 * PowerDNS from version 4.7 (released October 3, 2022) supports both 797 producing and consuming of catalog zones version 2 and consuming 798 of catalog zones version 1. PowerDNS does support the coo 799 property, and the group property on the producing side. 801 * Proof of concept python scripts (https://github.com/IETF- 802 Hackathon/NSDCatZ) that can be used for both generating and 803 consuming DNS Catalog Zones with NSD have been developed during 804 the hackathon at the IETF-109. 806 * BIND 9.18.3+ supports version 2 catalog zones as described in this 807 document including the coo property, as well as version 1 catalog 808 zones. 810 Interoperability between the above implementations has been tested 811 during the hackathon at the IETF-109. 813 Appendix C. Change History 815 *Note to the RFC Editor*: please remove this entire appendix before 816 publication. 818 * draft-muks-dnsop-dns-catalog-zones-00 820 | Initial public draft. 822 * draft-muks-dnsop-dns-catalog-zones-01 824 | Added Witold, Ray as authors. Fixed typos, consistency issues. 825 | Fixed references. Updated Area. Removed newly introduced custom 826 | RR TYPEs. Changed schema version to 1. Changed TSIG requirement 827 | from MUST to SHOULD. Removed restrictive language about use of 828 | DNS QUERY. When zones are introduced into a catalog zone, a 829 | primary SHOULD first make the new zones available for transfers 830 | first (instead of MUST). Updated examples, esp. use IPv6 in 831 | examples per Fred Baker. Add catalog zone example. 833 * draft-muks-dnsop-dns-catalog-zones-02 835 | Addressed some review comments by Patrik Lundin. 837 * draft-muks-dnsop-dns-catalog-zones-03 839 | Revision bump. 841 * draft-muks-dnsop-dns-catalog-zones-04 843 | Reordering of sections into more logical order. Separation of 844 | multi-valued properties into their own category. 846 * draft-toorop-dnsop-dns-catalog-zones-00 848 | New authors to pickup the editor pen on this draft 849 | 850 | Remove data type definitions for zone properties Removing 851 | configuration of member zones through zone properties altogether 852 | 853 | Remove Open issues and discussion Appendix, which was about zone 854 | options (including primary/secondary relationships) only. 856 * draft-toorop-dnsop-dns-catalog-zones-01 857 | Added a new section "The Serial Property", introducing a new 858 | mechanism which can help with disseminating zones from the primary 859 | to the secondary nameservers in a timely fashion more reliably. 860 | 861 | Three different ways to provide a "serial" property with a member 862 | zone are offered to or the workgroup for discussion. 863 | 864 | Added a new section "Implementation Status", listing production 865 | ready, upcoming and Proof of Concept implementations, and 866 | reporting on interoperability of the different implementations. 868 * draft-toorop-dnsop-dns-catalog-zones-02 870 | Adding the coo property for zone migration in a controlled fashion 871 | 872 | Adding the group property for reconfigure settings of member zones 873 | in an atomic update 874 | 875 | Adding the epoch property to reset zone associated state in a 876 | controlled fashion 878 * draft-toorop-dnsop-dns-catalog-zones-03 880 | Big cleanup! 881 | 882 | Introducing the terms catalog consumer and catalog producer 883 | 884 | Reorganized topics to create a more coherent whole 885 | 886 | Properties all have consistent format now 887 | 888 | Try to assume the least possible from implementations w.r.t.: 889 | 890 | 1) Predictability of the IDs of member zones 891 | 892 | 2) Whether or not fallback catalog zones can be found for a member 893 | 894 | 3) Whether or not a catalog consumer can maintain state 896 * draft-toorop-dnsop-dns-catalog-zones-04 898 | Move Implementation status to appendix 899 | 900 | Miscellaneous textual improvements 901 | 902 | coo property points to $NEWCATZ (and not zones.$NEWCATZ) 903 | 904 | Remove suggestion to increase serial and remove member zone from 905 | $OLDCATZ after migration 906 | 907 | More consistent usage of the terms catalog consumer and catalog 908 | producer throughout the document 909 | 910 | Better (safer) description of resetting refresh timers of member 911 | zones with the serial property 912 | 913 | Removing a member MUST remove zone associated state 914 | 915 | Make authentication requirements a bit less prescriptive in 916 | security considerations 917 | 918 | Updated implementation status for KnotDNS 919 | 920 | Describe member node name changes and update "Zone associated 921 | state reset" to use that as the mechanism for it. 922 | 923 | Add Peter Thomassen as co-author 924 | 925 | Complete removal of the epoch property. We consider consumer 926 | optimizations with predictable member node labels (for example 927 | based on a hash) out of the scope of this document. 928 | 929 | Miscellaneous editorial improvements 931 * draft-toorop-dnsop-dns-catalog-zones-05 933 | Add Kees Monshouwer as co-author 934 | 935 | Removed the "serial" property 936 | 937 | Allow custom properties on the global level 939 * draft-toorop-dnsop-dns-catalog-zones-06 941 | Move administrative control explanation to Security Considerations 942 | 943 | Move comment on query methods to Implementation Notes 944 | 945 | Clarify what happens on expiry 946 | 947 | Clarify catalog consumer behavior when MUST condition is violated 948 | 949 | Better text on ordering of operations for Change of Ownership 950 | 951 | Suggest to namespace custom properties 952 | 953 | Clarify how to handle property record with wrong type 954 | 955 | Cover the case of multiple different 's having the same 956 | value 957 | 958 | Recommendations for naming catalog zones 959 | 960 | Add and operational note about notifies for not yet existing zones 961 | 962 | Add text about name server restarts with broken zones 963 | 964 | Great power comes with great responsibility (Thanks Klaus!) 965 | 966 | Mention the new BIND implementation 967 | 968 | All invalid properties cause a broken catalog zone, including 969 | invalid group and version properties. 970 | 971 | Add Aram Sargsyan as author (he did the BIND9 implementation) 972 | 973 | group properties can have more than one value 975 * draft-toorop-dnsop-dns-catalog-zones-07 977 | Some spelling fixes from Tim Wicinski and Josh Soref 978 | 979 | Replace SHOULDs with MUSTs for ignoring things that are 980 | meaningless to a catalog consumer (Thanks Michael StJohns) 981 | 982 | Update the list of people to thank in the Acknowledgements section 983 | 984 | Mention PowerDNS support of catalog zones from version 4.7.0 985 | onwards 987 * draft-toorop-dnsop-dns-catalog-zones-08 989 | Address AD Review comments (editorial only) 990 | 991 | When DoT is mentioned, also mention now-standardized DoQ 993 * draft-toorop-dnsop-dns-catalog-zones-08 995 | Editorial nits from David Blacka, Lars Eggert, Russ Housley, Erik 996 | Kline, É (U+00C9)ric Vyncke and Paul Wouters 997 | 998 | Addes a Catalog Zone Exampla 999 | 1000 | Mention that the document uses DNS specific terminology and 1001 | reference RFC8499 1002 | 1003 | Added IANA Considerations sections, with a registry for Catalog 1004 | Zones properties 1005 | 1006 | Updated Implementation status also with respect to Catalog zones 1007 | version "1" support 1008 | 1009 | Updates to Rename "group properties" to "group property values" or 1010 | "group values" to reduce confusion about who will determine those 1011 | values (operators and not implementations) 1012 | 1013 | Change example group values in non descriptive names 1014 | 1015 | Add some more clarifications on that and how group values are 1016 | determined in producer/consumer agreements 1017 | 1018 | Stronger checking suggestion (SHOULD instead of MAY) in accepting 1019 | member zones by consumers in the Security section 1020 | 1021 | Added mistake recovery text to the Member zone removal section 1022 | 1023 | Replace vague language ("meaningless") with more precise wording 1024 | 1025 | Catalog consumers that know only version "2" MUST not process 1026 | version "1" catalog zones and consider it broken. 1027 | 1028 | The entire RDATA of a group property is it's value 1030 Authors' Addresses 1032 Peter van Dijk 1033 PowerDNS 1034 Den Haag 1035 Netherlands 1036 Email: peter.van.dijk@powerdns.com 1038 Libor Peltan 1039 CZ.NIC 1040 Czechia 1041 Email: libor.peltan@nic.cz 1043 Ondrej Sury 1044 Internet Systems Consortium 1045 Czechia 1046 Email: ondrej@isc.org 1048 Willem Toorop 1049 NLnet Labs 1050 Science Park 400 1051 1098 XH Amsterdam 1052 Netherlands 1053 Email: willem@nlnetlabs.nl 1055 Kees Monshouwer 1056 Netherlands 1057 Email: mind@monshouwer.eu 1059 Peter Thomassen 1060 deSEC, SSE - Secure Systems Engineering 1061 Berlin 1062 Germany 1063 Email: peter@desec.io 1065 Aram Sargsyan 1066 Internet Systems Consortium 1067 Email: aram@isc.org