<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="2" ipr="trust200902" docName="draft-albanna-regext-rdap-deleg-04" submissionType="IETF" category="std" xml:lang="en" indexInclude="true" consensus="true">

<front>
  <title abbrev="RDAP DELEG Extension">RDAP Extension for DNS DELEG</title>
  <seriesInfo value="draft-albanna-regext-rdap-deleg-04" stream="IETF" status="standard" name="Internet-Draft"/>
  <author initials="Z." surname="AlBanna" fullname="Zaid AlBanna">
    <organization>Verisign</organization>
    <address>
      <postal>
        <street>12061 Bluemont Way</street>
        <city>Reston</city>
        <code>20190</code>
        <country>US</country>
        <region>VA</region>
      </postal>
      <email>zalbanna@verisign.com</email>
    </address>
  </author>
  <author initials="S." surname="Hollenbeck" fullname="Scott Hollenbeck">
    <organization>Verisign</organization>
    <address>
      <postal>
        <street>12061 Bluemont Way</street>
        <city>Reston</city>
        <code>20190</code>
        <country>US</country>
        <region>VA</region>
      </postal>
      <email>shollenbeck@verisign.com</email>
    </address>
  </author>
  <date/>
  <area>Internet</area>
  <workgroup>Registration Extensions (REGEXT)</workgroup>

<abstract><t>
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries.
</t></abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>
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 <xref target="RFC9083"/>. The definition of DNS DELEG information is based on concepts described in Internet-Draft "Extensible Delegation for DNS" <xref target="DELEG"/> and Internet-Draft "Extensible Provisioning Protocol (EPP) mapping for DELEG records" <xref target="brown-epp-deleg"/>. This draft is subject to changes that may take place in [DELEG] and [brown-epp-deleg] as they are developed. This document describes how DNS DELEG record information can be included in RDAP responses that contain RDAP domain objects.
</t>

</section>

<section><name>Conventions used in this document</name>

<t>
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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>

</section>

<section anchor="rdap-conformance"><name>RDAP Conformance</name>
<t>RDAP responses that contain values described in this document MUST indicate conformance with this specification by including an rdapConformance (<xref target="RFC9083"/>) value of "deleg". The information needed to register this value in the RDAP Extensions Registry is described in <xref target="iana-considerations"/>.</t>
       
      <figure anchor="rdapConformance_example">
        <preamble>Example rdapConformance structure with extension specified:</preamble>
        <artwork xml:space="preserve">
   "rdapConformance" : 
     [
       "rdap_level_0",
       "deleg"
     ]
        </artwork>
      </figure>
</section>

<section anchor="rdap-response-specification"><name>RDAP Response Specification</name>
<t>This specification describes a new data structure that is used to return DNS DELEG information in a RDAP domain response. s described in Internet-Draft "Extensible Delegation for DNS" [DELEG], a DELEG record is a specialized form of a DNS SVCB [RFC9460] resource record. "deleg_delegInfo" is a data structure that contains information that describes DNS DELEG record information associated with a registered domain name. The "deleg_delegInfo" data structure is a list of objects. The list of objects contains the following members whose values and presentations are described in Section 2.1, and Appendix A of RFC 9460 <xref target="RFC9460"/>:</t>
		  
<t><list style="numbers">
                    <t>"priority": a number that represents the SvcPriority value of the record.</t>
                    <t>"target": a domain name that represents the TargetName of the record.</t>
            <t>"params": an OPTIONAL object that contains SvcParam key-value pairs.</t>
          </list></t>

<section><name>Examples of deleg_delegInfo</name>
<t>
Example 1: single DELEG AliasMode record type from a single provider based on the example shown in section 2.2 of [DELEG]:
</t>

<sourcecode><![CDATA[
        "deleg_delegInfo": [
          {
            "priority": 0,
            "target": "config1.example.net"
          }
        ]
]]></sourcecode>

<t>
Example 2: multiple DELEG AliasMode records type from multiple providers based on the example shown in section 2.2.1 of [DELEG]:
</t>

<sourcecode><![CDATA[
        "deleg_delegInfo": [
          {
            "priority": 0,
            "target": "config1.example.net"
          {
            "priority": 0,
            "target": "config1.example.org"
        ]
]]></sourcecode>

<t>
Example 3: single DELEG ServiceMode record type from a single provider based on the example shown in section 2.1 of [DELEG]:
</t>

<sourcecode><![CDATA[
       "deleg_delegInfo": [
          {
            "priority": 1,
            "target": "config3.example.net",
            "params": {
              "ipv6hint": "2001:db8:2423::3"
            }
          }
       ]
]]></sourcecode>

<t>
Example 4: multiple DELEG ServiceMode records type from multiple providers based on the example shown in section 5.1.1 of [brown-epp-deleg]:
</t>

<sourcecode><![CDATA[
       "deleg_delegInfo": [
          {
            "priority": 1,
            "target": "ns1.example.com",
            "params": {
              "ipv4hint": "192.0.2.1",
              "ipv6hint": "2001:DB8::1"
            }
          },
          {
            "priority": 1,
            "target": "ns2.example.net",
            "params": {
              "ipv4hint": "192.0.2.2",
              "ipv6hint": "2001:DB8::2"
            }
          }
       ]
]]></sourcecode>
</section>

<section><name>Examples of full RDAP responses including deleg_delegInfo</name>
<t>
Example 1: Domain object class with a single DELEG AliasMode record type: 
</t>

<sourcecode><![CDATA[{
  "objectClassName": "domain",
  "handle": "2336799_SomeHandle",
  "ldhName": "EXAMPLE.COM",
  "links": [
    ...
  ],
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "entities": [
    ...
  ],
  "events": [
    ...
  ],
  "secureDNS": {
    ...
  },
  "deleg_delegInfo": [
     {
        "priority": 0,
        "target" : "config1.example.net",
     }
  ],
  "nameservers": [
    {
      "objectClassName": "nameserver",
      "ldhName": "ns1.example.net"
    },
    {
      "objectClassName": "nameserver",
      "ldhName": "ns2.example.net"
    }
  ],
  "rdapConformance": [
    "rdap_level_0",
    "deleg"
  ],
  "notices": [
    ...
  ]
}]]></sourcecode>

<t>
Example 2: Domain object class with multiple DELEG ServiceMode records:
</t>
<sourcecode><![CDATA[{
  "objectClassName": "domain",
  "handle": "2336799_SomeHandle",
  "ldhName": "EXAMPLE.COM",
  "links": [
    {
      ...
    }
  ],
  "status": [
    "client delete prohibited",
    "client transfer prohibited",
    "client update prohibited"
  ],
  "entities": [
    ...
  ],
  "events": [
    ...
  ],
  "secureDNS": {
    ...
  },
  "deleg_delegInfo": [
     {
        "priority": 1,
        "target" : "ns1.example.com",
        "params": {
           "ipv4hint": "192.0.2.1",
           "ipv6hint": "2001:BE8::1"
         }
     },
     {
        "priority": 1,
        "target" : "ns2.example.net",
        "params": {
           "ipv4hint": "192.0.2.2",
           "ipv6hint": "2001:DB8::2"
         }
     }
  ],
  "nameservers": [
    {
      "objectClassName": "nameserver",
      "ldhName": "ns1.example.com"
    },
    {
      "objectClassName": "nameserver",
      "ldhName": "ns2.example.com"
    }
  ],
  "rdapConformance": [
    "rdap_level_0",
    "deleg"
  ],
  "notices": [
    ...
  ]
}]]></sourcecode>
</section>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>
IANA is requested to register the following value in the RDAP Extensions Registry:
</t>

<t>
<strong>Extension identifier:</strong> <tt>deleg</tt>
</t>

<t>
<strong>Registry operator:</strong> Any
</t>

<t>
<strong>Published specification:</strong> this document
</t>

<t>
<strong>Contact:</strong> IETF &lt;<eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref>&gt;
</t>

<t>
<strong>Intended usage:</strong> this extension describes how DNS DELEG records values can be included in RDAP responses.
</t>
</section>

<section anchor="security-cons"><name>Security Considerations</name>
<t>
The Security Considerations described in RFC 9083 <xref target="RFC9083"/> are applicable to this extension.
</t>
</section>

<section anchor="acknowledgements"><name>Acknowledgments</name>
<t>
The following individuals have provided feedback and contributions to the content and direction of this document:

James Gould 

</t>
</section>

</middle>

<back>
  <references>
    <name>Normative References</name>
    <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
    <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
    <reference anchor="RFC9083" target="https://www.rfc-editor.org/info/rfc9083">
  <front>
    <title>JSON Responses for the Registration Data Access Protocol (RDAP)</title>
    <author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck"/>
    <author fullname="A. Newton" initials="A." surname="Newton"/>
    <date month="June" year="2021"/>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="95"/>
  <seriesInfo name="RFC" value="9083"/>
  <seriesInfo name="DOI" value="10.17487/RFC9083"/>
</reference>
    <reference anchor="RFC9460" target="https://www.rfc-editor.org/info/rfc9460">
  <front>
    <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
    <author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
    <author fullname="M. Bishop" initials="M." surname="Bishop"/>
    <author fullname="E. Nygren" initials="E." surname="Nygren"/>
    <date month="November" year="2023"/>
    <abstract>
      <t>iThis 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.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="78"/>
  <seriesInfo name="RFC" value="9460"/>
  <seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
  </references>
  <references>
    <name>Informative References</name>
    <reference anchor="DELEG" target="https://datatracker.ietf.org/doc/draft-dnsop-deleg/">
  <front>
    <title>Extensible Delegation for DNS</title>
    <author fullname="P. Špaček" initials="P." surname="Špaček"/>
    <author fullname="R. Weber" initials="R." surname="Weber"/>
    <author fullname="D. Lawrence" initials="D." surname="Lawrence"/>
    <date month="March" year="2026"/>
    <abstract>
      <t>A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace.  Any facilities of that nameserver must be discovered through other mechanisms.  This document proposes a new extensible DNS record type, DELEG, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-dnsop-deleg-00"/>
</reference>
    <reference anchor="brown-epp-deleg" target="https://datatracker.ietf.org/doc/draft-brown-epp-deleg/">
  <front>
    <title>Extensible Provisioning Protocol (EPP) mapping for DELEG records</title>
    <author fullname="Gavin Brown" initials="G." surname="Brown">
      <organization>ICANN</organization>
    </author>
    <author fullname="Paul Hoffman" initials="P." surname="Hoffman">
      <organization>ICANN</organization>
    </author>
    <date day="26" month="January" year="2024"/>
    <abstract>
      <t>This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names.</t>
    </abstract>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-brown-epp-deleg"/>
</reference>
  </references>
</back>

</rfc>
