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
10
11 P. Thomassen
12 deSEC, SSE - Secure Systems Engineering
13 A. Sargsyan
14 Internet Systems Consortium
15 July 2023
16
17
18 DNS Catalog Zones
19
20 Abstract
21
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.
26
27 Status of This Memo
28
29 This is an Internet Standards Track document.
30
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.
36
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.
40
41 Copyright Notice
42
43 Copyright (c) 2023 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
45
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.
55
56 Table of Contents
57
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
85
86 1. Introduction
87
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.
98
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.
108
109 2. Terminology
110
111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
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.
116
117 Catalog zone: A DNS zone containing a DNS catalog, which is a list
118 of DNS zones and associated properties.
119
120 Member zone: A DNS zone whose configuration is published inside a
121 catalog zone.
122
123 Member node: A DNS name in the catalog zone representing a member
124 zone.
125
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).
130
131 Catalog producer: An entity that generates and is responsible for
132 the contents of the catalog zone.
133
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).
137
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].
144
145 3. Description
146
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.
152
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.
156
157 Authoritative servers may be pre-configured with multiple catalog
158 zones, each associated with a different set of configurations.
159
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.
163
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.
167
168 4. Catalog Zone Structure
169
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]).
173
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].
179
180 4.1. Member Zones
181
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.
185
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).
193
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:
197
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.
201
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).
206
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).
210
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).
214
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.
218
219 4.2. Properties
220
221 Catalog zone information is stored in the form of "properties".
222
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.
227
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).
232
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.
241
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.
245
246 4.2.1. Schema Version (version property)
247
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.
251
252 Catalog consumers MUST NOT apply catalog zone processing to:
253
254 * zones without the version property
255
256 * zones with a version property with more than one RR in the RRset
257
258 * zones with a version property without an expected value in the
259 version.$CATZ TXT RR
260
261 * zones with a version property with a schema version value that is
262 not implemented by the consumer (e.g., version "1")
263
264 These conditions signify a broken catalog zone, which MUST NOT be
265 processed (see Section 5.1).
266
267 For this memo, the value of the version.$CATZ TXT RR MUST be set to
268 "2"; that is:
269
270 version.$CATZ 0 IN TXT "2"
271
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.
274
275 4.3. Member Zone Properties
276
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.
282
283 4.3.1. Change of Ownership (coo property)
284
285 The coo property facilitates controlled migration of a member zone
286 from one catalog to another.
287
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:
294
295 <unique-N>.zones.$OLDCATZ 0 IN PTR example.com.
296 coo.<unique-N>.zones.$OLDCATZ 0 IN PTR $NEWCATZ
297
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).
301
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.
308
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).
318
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.
322
323 4.3.2. Groups (group property)
324
325 With a group property, a consumer(s) can be signaled to treat some
326 member zones within the catalog zone differently.
327
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.
334
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.
345
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.
350
351 4.3.2.1. Example
352
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.
356
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.
362
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.":
367
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"
373
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").
381
382 4.4. Custom Properties (*.ext properties)
383
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".
389
390 "ext" is not a placeholder. A custom property is named as follows:
391
392 ; a global custom property:
393 <property-prefix>.ext.$CATZ
394
395 ; a member zone custom property:
396 <property-prefix>.ext.<unique-N>.zones.$CATZ
397
398 <property-prefix> may consist of one or more labels.
399
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.
405
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).
409
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.
418
419 The meaning of the custom properties described in this section is
420 determined by the implementation alone without expectation of
421 interoperability.
422
423 5. Name Server Behavior
424
425 5.1. General Requirements
426
427 As it is a regular DNS zone, a catalog zone can be transferred using
428 DNS zone transfers among name servers.
429
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.
434
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).
439
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.
445
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.
450
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.
454
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.
458
459 5.2. Member Zone Name Clash
460
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.
465
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.
470
471 5.3. Member Zone Removal
472
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.
481
482 5.4. Member Node Name Change
483
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.
489
490 5.5. Migrating Member Zones between Catalogs
491
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.
498
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.
511
512 5.6. Zone-Associated State Reset
513
514 It may be desirable to reset state (such as zone data and DNSSEC
515 keys) associated with a member zone.
516
517 A zone state reset may be performed by a change of the member node's
518 name (see Section 5.4).
519
520 6. Implementation and Operational Notes
521
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].
528
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.
537
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.
542
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.
547
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.
561
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.
570
571 7. Security Considerations
572
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].
578
579 Use of DNS UPDATE [RFC2136] to modify the content of catalog zones
580 SHOULD similarly be authenticated.
581
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.
586
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].
591
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.
598
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).
606
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.
615
616 8. IANA Considerations
617
618 IANA has created the "DNS Catalog Zones Properties" registry under
619 the "Domain Name System (DNS) Parameters" registry as follows:
620
621 Registry Name: DNS Catalog Zones Properties
622
623 Assignment Policy: Expert Review, except for property prefixes
624 ending in the label "ext", which are for Private Use [RFC8126].
625
626 Reference: RFC 9432
627
628 Note: This registry applies to Catalog Zones schema version "2" as
629 specified in RFC 9432.
630
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 +-----------------+----------------------+-----------+-----------+
649
650 Table 1: DNS Catalog Zones Properties Registry
651
652 The meanings of the fields are as follows:
653
654 Property prefix: One or more domain name labels.
655
656 Description: A human-readable short description or name for the
657 property.
658
659 Status: IETF Stream RFC status or "External" if not documented in an
660 IETF Stream RFC.
661
662 Reference: A stable reference to the document in which this property
663 is defined.
664
665 9. References
666
667 9.1. Normative References
668
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>.
672
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>.
676
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>.
680
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>.
685
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>.
690
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>.
694
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>.
698
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>.
702
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>.
706
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>.
712
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>.
717
718 9.2. Informative References
719
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/>.
724
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>.
731
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>.
736
737 Appendix A. Catalog Zone Example
738
739 The following is a full example of a catalog zone containing three
740 member zones with various properties:
741
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. )
758
759 Acknowledgements
760
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.
764
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.
769
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.
774
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.
778
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.
784
785 Authors' Addresses
786
787 Peter van Dijk
788 PowerDNS
789 Den Haag
790 Netherlands
791 Email: peter.van.dijk@powerdns.com
792
793
794 Libor Peltan
795 CZ.NIC
796 Czech Republic
797 Email: libor.peltan@nic.cz
798
799
800 Ondrej Sury
801 Internet Systems Consortium
802 Czech Republic
803 Email: ondrej@isc.org
804
805
806 Willem Toorop
807 NLnet Labs
808 Science Park 400
809 1098 XH Amsterdam
810 Netherlands
811 Email: willem@nlnetlabs.nl
812
813
814 Kees Monshouwer
815 Netherlands
816 Email: mind@monshouwer.eu
817
818
819 Peter Thomassen
820 deSEC, SSE - Secure Systems Engineering
821 Berlin
822 Germany
823 Email: peter@desec.io
824
825
826 Aram Sargsyan
827 Internet Systems Consortium
828 Email: aram@isc.org
829
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.