]> TREX Regional Exchanges Oy

Kuninkaankatu 30 A Tampere 33720 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

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 for access control for those transfers. 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 and TSIG keys to use to transfer the member zones in a catalog, as well as properties to specify which IP addresses, using which TSIG keys, are allowed to notify the secondary name server serving the member zones, in order to remove the need to preprovision those at the catalog consumers.

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.

Description Body text [REPLACE]

Catalog Zone Structure These new properties can be at the top 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.

New Properties Body text [REPLACE]

Primaries Body text [REPLACE]

TSIG Key Name Body text [REPLACE]

TLSA Body text [REPLACE]

Allow Notify Body text [REPLACE]

Allow Transfer Body text [REPLACE]

Allow Query Body text [REPLACE]

Name Server Behavior Body text [REPLACE]

Implementation and Operational Notes Body text [REPLACE]

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 primaries Primary name servers Standards Track [this document] allow-notify Allow NOTIFY from 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 .

Security and Privacy Considerations Security and Privacy Considerations

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 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 Example Catalog with One of Everything

Acknowledgements Thanks everybody who helped making this work possible.

Contributors Thanks to all of the contributors.