Verisign

12061 Bluemont Way Reston 20190 US VA zalbanna@verisign.com

SAHollenbeck LLC

Nokesville 20181 US VA sah@sahollenbeck.com

Internet Registration Extensions (REGEXT) This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries.

Introduction This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries as described in section 5.3 of RFC 9083 . The definition of DNS DELEG information is based on concepts described in Internet-Draft "Extensible Delegation for DNS" and Internet-Draft "Extensible Provisioning Protocol (EPP) mapping for DELEG records" . This draft is subject to changes that may take place in [DELEG] and [brown-epp-deleg] as they are developed.

Conventions used in this document 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.

RDAP Conformance RDAP responses that contain values described in this document MUST indicate conformance with this specification by including an rdapConformance () value of "dnsDeleg". The information needed to register this value in the RDAP Extensions Registry is described in .

Example rdapConformance structure with extension specified: "rdapConformance" : [ "rdap_level_0", "dnsDeleg" ]

RDAP Response Specification This specification describes a new data structure that is used to return DNS DELEG information in an RDAP domain response. A new element, "DelegInfos", is defined to return a representation of DNS DELEG and DELEGPARAMS records. As described in Internet-Draft "Extensible Delegation for DNS" , a DELEG record is based on "SvcParams" for the SVCB record type RFC 9460 but differs from it by not having the "SvcPriority" and "TargetName" fields. The "DelegInfos" data structure is a JSON array whose members contain lists of key:value pairs (DelegInfoKey:DelegInfoValue) that describe DNS DELEG record information associated with a registered domain name. TBD: a full specification of the key-value pairs that can appear in a DelegInfos object. It may be possible to cite specific text from and/or ; we need to see how those specifications evolve.

Examples of the "DelegInfos" object Example 1: A DELEG record type based on a section A.1 of DELEG : Example 2: A DELEG record for domain names Acfg.example.org and subcfg.example.org, based on section A.2 of DELEG : Example 3: A DELEG record for domain name config2.example.org, based on section A.3 of DELEG : Example 4: An RDAP response that includes a DelegInfos object based on section A.4.3.1 of DELEG : Example 5: An RDAP response that includes a DelegInfos object based on section A.4.3.2 of DELEG :

IANA Considerations IANA is requested to register the following value in the RDAP Extensions Registry: Extension identifier: dnsDeleg Registry operator: Any Published specification: this document Contact: IETF <iesg@ietf.org> Intended usage: this extension describes how DNS DELEG record values can be included in RDAP responses.

Security Considerations The Security Considerations described in RFC 9083 are applicable to this extension.

Acknowledgments The following individuals have provided feedback and contributions to the content and direction of this document: James Gould

Normative References This document specifies a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGPARAM records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. In classic DNS, both parent and child zones contain copies of NS delegation records, which can potentially be out of sync and confusing. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information. ICANN ICANN This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names. 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 JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. Informative References This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Change History

Change from 04 to 05

1. Removed reference to the members of the list object, priority and target
2. Updated JSON data structure name from delegInfo to DelegInfos as per draft-ietf-deleg-11
3. Changed examples to be based on the examples provided in draft-ietf-deleg-11
4. Reorganized references.
5. Added a change history section