DNS Catalog Zones
Extracted elements (27)
Catalog zones leverage the existing AXFR/IXFR zone transfer mechanism for distributing configuration changes to secondary name servers, avoiding the need for a new protocol and enabling automatic propagation with no implementation-specific provisioning tooling.
Member zone names are placed in the RDATA of PTR records rather than as owner name labels so that all valid domain names may be represented regardless of their length, since DNS label length constraints would otherwise prevent some names from being encoded as owner names.
Properties are structured as DNS RRsets under a member node rather than encoded in owner-name labels, so that arbitrary property types and multi-valued properties can be added without expanding the naming hierarchy in ways that conflict with length limits.
If not all consumers support the coo property, migration must be performed by first removing the member zone from $OLDCATZ and then adding it to $NEWCATZ. Consumers that miss the removal may interpret the addition as a name clash, leaving the zone unmigrated; recovery from that situation is out of scope.
A catalog producer MUST NOT use catalog zone names that are not under the control of the catalog producer, with the exception of reserved names. Using a domain owned by the producer or a name under 'invalid.' (RFC 6761) is RECOMMENDED.
A catalog zone MUST follow the usual rules for DNS zones; SOA and NS record sets MUST be present. A single NS RR with NSDNAME 'invalid.' is RECOMMENDED to satisfy syntactic correctness without implying recursive accessibility.
Catalog consumers MUST ignore any RRs in the catalog zone for which no processing is specified or which are otherwise not supported by the implementation.
Catalog consumers MUST NOT apply catalog zone processing to zones without the version property, zones with more than one version RR, zones with an unexpected value, or zones declaring a schema version not implemented by the consumer (e.g., version "1").
Custom properties MUST be represented below the label 'ext' (e.g., '<property-prefix>.ext.$CATZ' for global or '<property-prefix>.ext.<unique-N>.zones.$CATZ' for member-scoped). Implementations SHOULD namespace their custom properties to reduce clash risk with other implementations.
If a name clash occurs between an existing zone and an incoming member zone (via transfer or update), the new instance MUST be ignored and an error SHOULD be logged. A clash MUST NOT be treated as a migration attempt except via the coo mechanism.
Unless the member node label (<unique-N>) is the same in $NEWCATZ, all zone-associated state for a just-migrated zone MUST be reset. The original catalog owner must change the label (triggering a state reset) before or simultaneously with adding the coo property to prevent state takeover by the new owner.
When a catalog zone expires it loses its catalog meaning and MUST no longer be processed as such. No special processing of member zones occurs until the zone becomes fresh again.
When a consumer receives a coo property update in $OLDCATZ, it MUST NOT migrate the member zone immediately; migration must wait until the member zone appears in $NEWCATZ. Before migrating, the consumer MUST verify that the coo property pointing to $NEWCATZ is still present in $OLDCATZ.
When a member zone is removed from a catalog, a consumer MUST NOT remove the zone if it was not originally configured from that specific catalog. The zone and all associated state (zone data, DNSSEC keys) MUST be removed only when the zone was initially added from the same catalog.
When a name server supporting catalog zones completes a transfer, it SHOULD apply changes automatically without manual intervention. When a catalog zone becomes broken, member zones configured by it MUST NOT be removed or reconfigured; the catalog loses its meaning until repaired.
Catalog zones reveal the full set of zones served by their consumers, including associated properties. Operators SHOULD limit the systems able to query catalog zones and SHOULD conduct catalog zone transfers confidentially per RFC 9103 to prevent unintentional exposure.
A catalog zone is a regular DNS zone whose contents are specially crafted: PTR records under the 'zones' label list member zones, and additional RRsets encode properties. All RRs MUST have CLASS IN (1); TTL values carry no meaning and SHOULD be ignored.
Member zones are represented as PTR records at '<unique-N>.zones.$CATZ' with TTL 0. Each PTR RRset MUST contain exactly one record; more than one PTR in the same RRset, or two RRs pointing to the same member zone, indicates a broken catalog zone that MUST NOT be processed.
The coo (Change of Ownership) property is a single PTR record at 'coo.<unique-N>.zones.$OLDCATZ' whose RDATA is the name of the new catalog zone. It signals a controlled migration of the member zone without immediately triggering that migration on the consumer.
The group property is stored as TXT RDATA directly below the member node. Its value is opaque and interpreted solely by agreement between producer and consumer(s). A member zone may carry multiple group values; consumers MUST ignore group values they do not understand.
The schema version is stored as a TXT RR named 'version.$CATZ'. For this specification the value MUST be "2" and the RRset MUST contain exactly one RR. Version "1" was used in earlier drafts and is reflected in the BIND 9.11 implementation.
IANA created the 'DNS Catalog Zones Properties' registry under 'Domain Name System (DNS) Parameters'. Assignment policy is Expert Review; prefixes ending in 'ext' are Private Use. Initial entries: zones (member zone list), version (schema version), coo (change of ownership), group (grouping), and *.ext (custom/private use).
Administrative control over what zones are served shifts entirely to the catalog producer. Consumers SHOULD scope the set of admissible member zones by suitable means (static regular expressions, dynamic verification against another database) to prevent unintended provisioning.
Catalog zone transfers SHOULD be protected via TSIG (RFC 8945) or Strict/Mutual TLS using DNS Zone Transfer over TLS/QUIC (RFC 9103). DNS UPDATE modifications to catalog zones SHOULD similarly be authenticated. Zone transfers of member zones SHOULD also be authenticated.
During coo-based migration, the new catalog owner can silently take over all zone-associated state (including DNSSEC keys) by retaining the same member node label. The original owner must enforce a state reset by changing the label before or simultaneously with publishing the coo property.
TSIG shared secrets used for member zones SHOULD NOT appear in the catalog zone data, though key identifiers may be shared within catalog zones.
When a member node's label (<unique-N>) changes, consumers MUST treat this as a member zone removal (including removal of all associated state per Section 5.3), immediately followed by addition of the zone as a newly configured member. This is also the mechanism for an explicit zone-associated state reset.