DNSOP Working Group A. Suhonen Internet-Draft TREX Updates: 9432 (if approved) W. Toorop Intended status: Standards Track NLnet Labs Expires: 30 March 2026 A. Buddhdev RIPE NCC K. Dyson Nominet UK A. Sargsyan Internet Systems Consortium 26 September 2025 DNS Catalog Zone Properties for Zone Transfers draft-axu-dnsop-catalog-zone-xfr-properties-01 Abstract This document specifies DNS Catalog Zones Properties that define the primary name servers from which specific or all member zones can transfer their associated zone, as well as properties related to zone transfers such as access control. This document also defines a groups property, for the apex of the catalog zone, as a location to assign the additional properties to certain catalog zone groups. Besides the additional properties, this document updates RFC9432 by explicitly allowing CNAMEs and DNAMEs. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-axu-dnsop-catalog-zone-xfr- properties/. Discussion of this document takes place on the dnsop Working Group mailing list (mailto:dnsop@iets.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/https://github.com/DNS-Hackathon/catalog- extensions-draft. Suhonen, et al. Expires 30 March 2026 [Page 1] Internet-Draft catalog-zone-xfr-properties September 2025 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 March 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements language . . . . . . . . . . . . . . . . . . 3 2. Catalog Zone Structure . . . . . . . . . . . . . . . . . . . 4 2.1. Binding additional attributes . . . . . . . . . . . . . . 4 2.2. CNAMEs and DNAMEs . . . . . . . . . . . . . . . . . . . . 4 3. New Properties . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Primaries . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. TSIG Key Name . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Signalling encrypted transports . . . . . . . . . . . 5 3.2. Notify . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. TSIG Key Name . . . . . . . . . . . . . . . . . . . . 6 3.3. Allow Query . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. TSIG Key Name . . . . . . . . . . . . . . . . . . . . 7 3.4. Allow Transfer . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. TSIG Key Name . . . . . . . . . . . . . . . . . . . . 8 Suhonen, et al. Expires 30 March 2026 [Page 2] Internet-Draft catalog-zone-xfr-properties September 2025 4. Assigning properties to groups . . . . . . . . . . . . . . . 9 4.1. Groups (the groups property) . . . . . . . . . . . . . . 9 5. Implementation and Operational Notes . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 8. Security and Privacy Considerations . . . . . . . . . . . . . 11 8.1. Private Zone Exfiltration . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Example Catalog with One of Everything . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction DNS Catalog Zones [RFC9432] described a method for automatic DNS zone provisioning among DNS name servers by the catalog of zones to be provisioned as one or more regular DNS zones. Configuration associated with the member zones, such as from which primary name servers and with which TSIG keys [RFC8945] to transfer the zones, and from which IP addresses and with which TSIG keys DNS notifies [RFC1996] are allowed, were assumed to be preprovisioned at the catalog consumer. This document specifies DNS Catalog Zones Properties to specify primary name servers from which to transfer the member zones, as well as properties to specify which IP addresses, using which cryptographic keys, are allowed to notify the secondary name server serving the member zones, in order to: * remove the necessity to preprovision those at the catalog consumers, * to fascilitate ad-hoc changes, and * to fascilitate exceptions for individual member zones. 1.1. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Suhonen, et al. Expires 30 March 2026 [Page 3] Internet-Draft catalog-zone-xfr-properties September 2025 2. Catalog Zone Structure The new properties, specified in Section 3, MAY be at the apex of the catalog zone, where they will affect all member zones, or under a member zone label, where they will affect just that member zone. Any property under a member zone label will override that same property at the apex. 2.1. Binding additional attributes It is possible to distinguish groups of values with all the properties from Section 3, by adding an additional label before the property. This allows binding additional attributes within the group, for example binding TSIG keys to certain IP addresses. 2.2. CNAMEs and DNAMEs This document updates [RFC9432] by explicitly allowing CNAMEs [RFC1035] and DNAMEs [RFC6672] anywhere in the catalog. The CNAME and DNAME RRs in an catalog zone MUST refer to names within the same (catalog) zone. When a CNAME and DNAME RRs refer to owner names outside of the (catalog) zone, they MUST be considered invalid and MUST be ignored. For example, using some of the properties from Section 3: ZONELABEL1.zones.$CATZ 0 IN PTR example.com. ZONELABEL1.zones.$CATZ 0 IN DNAME customer1.config.$CATZ primaries.customer1.config.$CATZ 0 IN A 192.0.2.53 primaries.customer1.config.$CATZ 0 IN TXT "TSIG key" allow-transfer.customer1.config.$CATZ 0 IN CNAME internal.acls.config.$CATZ internal.acls.config.$CATZ 0 IN APL 1:10.0.0.0/8 2:fd00:0:0:0:0:0:0:0/8 3. New Properties 3.1. Primaries This property defines which server(s) the member zone(s) will be fetched from. The RR types on this property MUST be either A or AAAA. If there are multiple RRs, the order in which they are used or tried is undefined. The order may be used following the default selection process in use by the catalog consumer name server software. Different primaries MAY be distinguished by an additional label, which will allow binding additional attributes to each server. Suhonen, et al. Expires 30 March 2026 [Page 4] Internet-Draft catalog-zone-xfr-properties September 2025 primaries.$CATZ 0 IN A 192.0.2.53 ZONELABEL1.zones.$CATZ 0 IN PTR example.com. primaries.ZONELABEL1.zones.$CATZ 0 IN AAAA 2001:db8:35::53 If there are any RRs attached to the primaries that are not covered by this document, they SHOULD be ignored. 3.1.1. TSIG Key Name The primaries property, with or without the extra label, MAY also have a TXT resource record set (RRset), which MUST consist of a single TXT RR, which will contain the name of the TSIG key to use to protect zone transfers. The key(s) MUST be defined elsewhere, such as in the configuration file of the consumer. If the key cannot be found, the consumer MUST NOT attempt a zone transfer from the name server addresses for which the TXT RRset was an additional attribute. A TXT RRset for a primaries property containing more than a single TXT RR indicates a broken catalog zone that MUST NOT be processed (see Section 5.1 of [RFC9432]). ZONELABEL2.zones.$CATZ 0 IN PTR example.net. ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN AAAA 2001:db8:35::53 ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN TXT "keyname-for-ns1" ns2.primaries.ZONELABEL2.zones.$CATZ 0 IN AAAA 2001:db8:35::54 ns2.primaries.ZONELABEL2.zones.$CATZ 0 IN TXT "keyname-for-ns2" 3.1.2. Signalling encrypted transports The primaries property, _with_ the extra label, MAY also have a TLSA RRset with one or more TLSA RRs [RFC6698]. The presence of a TLSA RRset signals support of DNS over TLS (DoT) [RFC7858] or DNS over QUIC (DoQ) [RFC9250] by the primary and the means by which the catalog consumer can successfully authenticate the primary. TLSA RRsets MUST be prepended by two labels (below the property label _with_ the extra label) indicating the decimal representation of the port number (see Section 3 of [RFC6698]) and the protocol name of the transport (see Section 4 of [I-D.draft-ietf-dnsop-svcb-dane-05]). Catalog consumers MUST transfer member zone and incremental updates over either DoT or DoQ in the presence of a TLSA RRset. An authentication domain name (see Section 2 of [RFC8310]) MAY be provided by a PTR RRset, which MUST consist of a single PTR RR, at the same name as the TLSA RRset. When an authentication domain name is provided, catalog consumer MUST send the TLS SNI extension containing that name. Suhonen, et al. Expires 30 March 2026 [Page 5] Internet-Draft catalog-zone-xfr-properties September 2025 For the same reasons as given in Section 3.1.3 of [RFC7672], the TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1) SHOULD NOT be included. Usage of such RRs by catalog consumers is undefined. Catalog consumers MAY treat such RRs as "unusable". ZONELABEL2.zones.$CATZ 0 IN PTR example.net. ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN AAAA 2001:db8:35::53 _853._quic.ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN PTR ns1.example.net. _853._quic.ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN TLSA 3 1 1 \ 3.2. Notify This property MAY be used to define the DNS NOTIFY [RFC1996] message sending behavior of the consumer for the target zone(s). A and AAAA RRsets list hosts that the consumer will send DNS NOTIFY messages to when it loads a new version of the target zone(s). An additional label below the property name MAY be used to distinguish different groups of addresses, which will allow binding additional attributes to each group. 3.2.1. TSIG Key Name The notify property, with or without the extra label, MAY also have a TXT RRset, which MUST consist of a single TXT RR, which will contain the name of the TSIG key to use to sign the NOTIFY message. The key(s) MUST be defined elsewhere, such as in the configuration file of the consumer. If the key cannot be found, the consumer MUST NOT notify the name server addresses for which the key was an additional attribute. A TXT RRset for a notify property containing more than a single TXT RR indicates a broken catalog zone that MUST NOT be processed (see Section 5.1 of [RFC9432]). notify.$CATZ 0 IN A 192.0.2.49 notify.$CATZ 0 IN TXT "name-of-default-key" ZONELABEL3.zones.$CATZ 0 IN PTR example.org. notify.ZONELABEL3.zones.$CATZ 0 IN AAAA 2001:db8:35::53 notify.ZONELABEL3.zones.$CATZ 0 IN TXT "keyname-for-ns4" ns5.notify.ZONELABEL4.zones.$CATZ 0 IN AAAA 2001:db8:35::54 ns5.notify.ZONELABEL4.zones.$CATZ 0 IN TXT "keyname-for-ns5" If there are any RRs attached to the notify property that are not covered by this document, they SHOULD be ignored. Suhonen, et al. Expires 30 March 2026 [Page 6] Internet-Draft catalog-zone-xfr-properties September 2025 3.3. Allow Query The allow-query property MAY be used to define an access list of hosts or networks that are allowed to send queries for the target zone(s). The property MAY contain a RRset of type APL [RFC3123], which MUST consist of only a single APL RR. The prefixes listed in the APL RR are processed in order: - An IP address is allowed to query the zone when it matches a prefix. - An IP address is denied to query the zone when it matches a negated prefix. The absence of an allow-query property at both apex of the catalog as well as at a member zone, means that the default policy applies, which may be that the member zone is allowed to be queried from any IP address without TSIG key. Additional attributes (such as TSIG keys) can be bound to specific APL RRs by an additional label below the property label. The prefixes (with or without attributes) will be processed in Section 6 of canonical order [RFC4034], which means that the RRsets at the allow-query property label will be processed first, followed by the RRsets with the additional label in canonical order. When a catalog consumer encounters an APL RRset containing more that a single APL RR, MUST be interpreted as an APL RRset containing a single APL RR denying all IP addresses, i.e.: APL !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0. 3.3.1. TSIG Key Name The allow-query property MAY also have a TXT RRset, which will (further) restrict the zone to be queryable only with the TSIG keys indicated in any of the TXT RRs in the set. The key(s) MUST be defined elsewhere, such as in the configuration file of the consumer. If a TXT RRset is present together with an APL RR, then first the policies in the APL are applied, and if that results in queries being allowed for the IP address, then in addition a TSIG key MUST match any of the TXT RRs in the TXT RRset. If a TXT RRset is present without an APL RRset, then only a TSIG key MUST match in any of the TXT RRs in the TXT RRset, regardless of the querying IP address. If an allow-query property is present _and_ contains APL RRsets and/ or TXT RRsets (either directly below the property label or below the additional label), _and_ none of the ACLs and/or TSIG keys matched or could be found, then the consumer MUST NOT allow queries for the member zone to which the property applies. Suhonen, et al. Expires 30 March 2026 [Page 7] Internet-Draft catalog-zone-xfr-properties September 2025 ZONELABEL5.zones.$CATZ 0 IN PTR example.local. 00-internal.allow-query.ZONELABEL5.zones.$CATZ 0 IN APL 1:10.0.0.0/8 2:fd00:0:0:0:0:0:0:0/8 50-external.allow-query.ZONELABEL5.zones.$CATZ 0 IN TXT "keyname" 3.4. Allow Transfer The allow-transfer property MAY be used to define an access list of hosts or networks that are allowed to transfer the target zone(s) from the consumer. The property MAY contain a RRset of type APL [RFC3123], which MUST consist of only a single APL RR. The prefixes listed in the APL are processed in order: - An IP address is allowed to query the zone when it matches a prefix. - An IP address is denied to query the zone when it matches a negated prefix. The absence of an allow-transfer property at both apex of the catalog as well as at a member zone, signifies that transfers of the zone from the consumer MUST NOT be allowed. Additional attributes (such as TSIG keys) can be bound to specific APL RRs by an additional label below the property label. The prefixes (with or without attributes) will be processed in Section 6 of canonical order [RFC4034], which means that the RRsets at the allow-transfer property label will be processed first, followed by the RRsets with the additional label in canonical order. When a catalog consumer encounters an APL RRset containing more that a single APL RR, MUST be interpreted as an APL RRset containing a single APL RR denying all IP addresses, i.e.: APL !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0. 3.4.1. TSIG Key Name The allow-transfer property MAY also have a TXT RRset, which will (further) restrict the zone to be transferable only with the TSIG key indicated in any of the TXT RRs in the set. The key(s) MUST be defined elsewhere, such as in the configuration file of the consumer. If a TXT RRset is present together with an APL RR, then first the policies in the APL are applied, and if that results in transfers being allowed for the IP address, then in addition a TSIG key MUST match any of the TXT RRs in the TXT RRset. If a TXT RRset is present without an APL RRset, then only a TSIG key MUST match in any of the TXT RRs in the TXT RRset, regardless of the querying IP address. If an allow-transfer property is present _and_ contains APL RRsets and/or TXT RRsets (either directly below the property label or below the additional label), _and_ none of the APLs and/or TSIG keys matched or could be found, then the consumer MUST NOT allow transfers of the member zone to which the property applies. Suhonen, et al. Expires 30 March 2026 [Page 8] Internet-Draft catalog-zone-xfr-properties September 2025 ZONELABEL5.zones.$CATZ 0 IN PTR example.local. 00-internal.allow-transfer.ZONELABEL5.zones.$CATZ 0 IN APL 1:10.0.0.0/8 2:fd00:0:0:0:0:0:0:0/8 50-external.allow-transfer.ZONELABEL5.zones.$CATZ 0 IN TXT "keyname" If there are RRs other than APL or CNAME attached to the allow- transfer property, and if an APL RR cannot be found or there is a CNAME that doesn't point to an APL, then the most restrictive access list possible SHOULD be assumed. 4. Assigning properties to groups It is possible to assign the properties from this document to catalog groups (see Section 4.3.2. of [RFC9432]). To this end this document introduces the groups property. 4.1. Groups (the groups property) The list of calalog group that have properties assigned to it, is specified as a collection of member nodes represented by TXT RRs under the owner name "groups" where "groups" is a direct child domain of the catalog zone. The names of member zones are represented on the RDATA side of a TXT record (instead of being represented as a part of owner names) so that all valid group names may be represented. This TXT record MUST be the only record in the TXT RRset with the same name. The presence of more than one record in the RRset indicates a broken catalog zone that MUST NOT be processed (see Section 5.1. of [RFC9432]). For example, if a catalog zone lists two catalog groups ("foo" and "bar"), the member node RRs would appear as follows: .groups.$CATZ 0 IN TXT "foo" .groups.$CATZ 0 IN TXT "bar" where is a label that tags each record in the collection and has a unique value. When different labels hold the same TXT value (i.e., provide more than a single place to assign properties to the same group), the catalog zone is broken and MUST NOT be processed (see Section 5.1. of [RFC9432]). Properties assigned to a catalog group, below an entry below the groups property extends the configuration that was already associated with that group. If the existing configuration for the group had a configuration value, that is also targeted with property assigned for the group, then the assigned properties value MUST override the original value. If there was no existing group yet, then an entry below the groups property defines the new group. Suhonen, et al. Expires 30 March 2026 [Page 9] Internet-Draft catalog-zone-xfr-properties September 2025 5. Implementation and Operational Notes One of the rationales for allowing CNAMEs and DNAMEs is that a large and complex catalog may have large and complex access lists repeated a million times. But if there are only a few different access lists, they could be defined separately and then be referenced a million times, reducing both the size and processing effort of the catalog zone. Alternatively, a group property may be used for this, which will or will not have additional properties assigned to it under the groups property (see Section 4). 6. IANA Considerations IANA is requested to add the following entries to the "DNS Catalog Zones Properties" registry under the "Domain Name System (DNS) Parameters" page: +=================+========================+===========+===========+ | Property Prefix | Description | Status | Reference | +=================+========================+===========+===========+ | groups | List of catalog groups | Standards | [this | | | | track | document] | +-----------------+------------------------+-----------+-----------+ | primaries | Primary name servers | Standards | [this | | | | Track | document] | +-----------------+------------------------+-----------+-----------+ | notify | Send DNS NOTIFY | Standards | [this | | | behavior | track | document] | +-----------------+------------------------+-----------+-----------+ | allow-transfer | Allow zone transfer | Standards | [this | | | from | track | document] | +-----------------+------------------------+-----------+-----------+ | allow-query | Allow queries from | Standards | [this | | | | track | document] | +-----------------+------------------------+-----------+-----------+ Table 1 7. Implementation Status *[NOTE to the RFC Editor: Please remove this section before publication]* This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft [RFC7942]. Suhonen, et al. Expires 30 March 2026 [Page 10] Internet-Draft catalog-zone-xfr-properties September 2025 The existing BIND 9 implementation of primaries, allow-transfer and allow-query was a major inspiration for writing this draft. 8. Security and Privacy Considerations The original RFC for Catalog Zones already covers a lot of security and privacy considerations, and they are all still valid, but there are also new security considerations introduced by this document. 8.1. Private Zone Exfiltration If the Catalog Zone producer and consumer are different organizations, the producer may be able to use a crafted Catalog Zone to exfiltrate a private zone on another server within the consumer's network by listing it in the Catalog Zone with more permissive query or transfer access lists. The producer needs to know the exact name of the private zone and an address of the primary where the consumer may fetch it from. There are two ways to approach this security issue. One is to make sure that the consumer organisation does not allow zone transfers for private zones on the consuming server. Another approach is to sanitize the incoming Catalog Zone before consuming it, removing anything sensitive from it. 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, . Suhonen, et al. Expires 30 March 2026 [Page 11] Internet-Draft catalog-zone-xfr-properties September 2025 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . Suhonen, et al. Expires 30 March 2026 [Page 12] Internet-Draft catalog-zone-xfr-properties September 2025 [RFC9432] van Dijk, P., Peltan, L., Surý, O., Toorop, W., Monshouwer, C.R., Thomassen, P., and A. Sargsyan, "DNS Catalog Zones", RFC 9432, DOI 10.17487/RFC9432, July 2023, . 9.2. Informative References [I-D.draft-ietf-dnsop-svcb-dane-05] Schwartz, B. M. and R. Evans, "Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC", Work in Progress, Internet-Draft, draft-ietf- dnsop-svcb-dane-05, 3 March 2025, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Appendix A. Example Catalog with One of Everything primaries.$CATZ 0 IN A 192.0.2.53 ZONELABEL1.zones.$CATZ 0 IN PTR example.com. primaries.ZONELABEL1.zones.$CATZ 0 IN AAAA 2001:db8:35::53 ZONELABEL2.zones.$CATZ 0 IN PTR example.net. ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN AAAA 2001:db8:35::53 ns1.primaries.ZONELABEL2.zones.$CATZ 0 IN TXT "keyname-for-ns1" ns2.primaries.ZONELABEL2.zones.$CATZ 0 IN AAAA 2001:db8:35::54 ns2.primaries.ZONELABEL2.zones.$CATZ 0 IN TXT "keyname-for-ns2" notify.$CATZ 0 IN A 192.0.2.49 ZONELABEL3.zones.$CATZ 0 IN PTR example.org. notify.ZONELABEL3.zones.$CATZ 0 IN AAAA 2001:db8:35::53 notify.ZONELABEL3.zones.$CATZ 0 IN TXT "no default notifies" ZONELABEL4.zones.$CATZ 0 IN PTR sub.example.org. notify.ZONELABEL4.zones.$CATZ 0 IN AAAA 2001:db8:35::54 notify.ZONELABEL4.zones.$CATZ 0 IN TXT "" ZONELABEL5.zones.$CATZ 0 IN PTR example.local. allow-query.ZONELABEL5.zones.$CATZ 0 IN APL 1:10.0.0.0/8 !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0 allow-transfer.ZONELABEL5.zones.$CATZ 0 IN APL !1:0.0.0.0/0 !2:0:0:0:0:0:0:0:0/0 Suhonen, et al. Expires 30 March 2026 [Page 13] Internet-Draft catalog-zone-xfr-properties September 2025 Acknowledgements Thanks everybody who helped making this work possible. Contributors Thanks to all of the contributors. Authors' Addresses Aleksi Suhonen TREX Regional Exchanges Oy Kuninkaankatu 30 A FI-33200 Tampere Finland Email: i-d-2025@ssd.axu.tm Willem Toorop NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands Email: willem@nlnetlabs.nl Anand Buddhdev RIPE NCC Stationsplein 11 1012 AB Amsterdam Netherlands Email: anandb@ripe.net Karl Dyson Nominet UK Oxford Science Park Oxford OX4 4DQ United Kingdom Email: karl.dyson@nominet.uk URI: https://nominet.uk Aram Sargsyan Internet Systems Consortium Email: aram@isc.org Suhonen, et al. Expires 30 March 2026 [Page 14]