]> TREX Regional Exchanges Oy

Kuninkaankatu 30 A Tampere 33200 FI i-d-2025@ssd.axu.tm

NLnet Labs

Science Park 400 Amsterdam 1098 XH NL willem@nlnetlabs.nl

RIPE NCC

Stationsplein 11 Amsterdam 1012 AB NL anandb@ripe.net

Nominet UK

Oxford Science Park Oxford OX4 4DQ UK karl.dyson@nominet.uk https://nominet.uk

Internet Systems Consortium

aram@isc.org

Operations and Management Area DNSOP Working Group DNS authoritative catalog zones properties 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. Status information for this document may be found at . Discussion of this document takes place on the dnsop Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction DNS Catalog Zones 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 to transfer the zones, and from which IP addresses and with which TSIG keys DNS notifies 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.

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 when, and only when, they appear in all capitals, as shown here.

Catalog Zone Structure The new properties, specified in , 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.

Binding additional attributes It is possible to distinguish groups of values with all the properties from , 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.

CNAMEs and DNAMEs This document updates by explicitly allowing CNAMEs and DNAMEs 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 :

New Properties

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.

If there are any RRs attached to the primaries that are not covered by this document, they SHOULD be ignored.

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 ).

Signalling encrypted transports The primaries property, with the extra label, MAY also have a TLSA RRset with one or more TLSA RRs . The presence of a TLSA RRset signals support of DNS over TLS (DoT) or DNS over QUIC (DoQ) 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 ) and the protocol name of the transport (see ). 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 ) 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. For the same reasons as given in , 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".

]]>

Notify This property MAY be used to define the DNS NOTIFY 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.

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 ).

If there are any RRs attached to the notify property that are not covered by this document, they SHOULD be ignored.

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, 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 canonical order, 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.

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.

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, 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 canonical order, 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.

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.

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.

Assigning properties to groups It is possible to assign the properties from this document to catalog groups (see ). To this end this document introduces the groups property.

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 ). 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 <unique-N> is a label that tags each record in the collection and has a unique value. When different <unique-N> 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 ). 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.

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 ).

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 track [this document] primaries Primary name servers Standards Track [this document] notify Send DNS NOTIFY behavior Standards track [this document] allow-transfer Allow zone transfer from Standards track [this document] allow-query Allow queries from Standards track [this document]

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 . The existing BIND 9 implementation of primaries, allow-transfer and allow-query was a major inspiration for writing this draft.

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.

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.

This document describes a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Meta Platforms, Inc. Google LLC Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Example Catalog with One of Everything

Acknowledgements Thanks everybody who helped making this work possible.

Contributors Thanks to all of the contributors.