draft-wesplaap-deleg.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-wesplaap-deleg-latest" category="std" consensus="true" submissionType="IETF" updates="1035" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.27.0 -->
  <front>
    <title abbrev="DELEG">Extensible Delegation for DNS</title>
    <seriesInfo name="Internet-Draft" value="draft-wesplaap-deleg-latest"/>
    <author initials="T." surname="April" fullname="Tim April">
      <organization>Google, LLC</organization>
      <address>
        <email>ietf@tapril.net</email>
      </address>
    </author>
    <author initials="P." surname="Špaček" fullname="Petr Špaček">
      <organization>ISC</organization>
      <address>
        <email>pspacek@isc.org</email>
      </address>
    </author>
    <author initials="R." surname="Weber" fullname="Ralf Weber">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rweber@akamai.com</email>
      </address>
    </author>
    <author initials="D." surname="Lawrence" fullname="David C Lawrence">
      <organization>Salesforce</organization>
      <address>
        <email>tale@dd.org</email>
      </address>
    </author>
    <date/>
    <area>Internet</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 113?>
<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.</t>
      <t>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, for delegation of the authority for a domain. Future documents then can use this mechanism to use additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace.</t>
    </abstract>
  </front>
  <middle>
    <?line 117?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>In the Domain Name System <xref target="STD13"/>, subdomains within the domain name hierarchy are indicated by delegations to servers which are authoritative for their portion of the namespace.  The DNS records that do this, called NS records, contain hostnames of nameservers, which resolve to addresses.  No other information is available to the resolver. It is limited to connect to the authoritative servers over UDP and TCP port 53. This limitation is a barrier for efficient introduction of new DNS technology.</t>
      <t>The proposed DELEG record type remedies this problem by providing extensible parameters to indicate capabilities and additional information, such as glue that a resolver may use for the delegated authority. It is authoritative and thus signed in the parent side of the delegation making it possible to validate all delegation parameters (names and glue records) with DNSSEC.</t>
      <t>This document only shows how DELEG can be used instead of or along side a NS record to create a delegation. Future documents can use the extensible mechanism for more advanced features like connecting to a name server with an encrypted transport.</t>
      <section anchor="terminology">
        <name>Terminology</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 <br/>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.</t>
        <t>Terminology regarding the Domain Name System comes from <xref target="BCP219"/>, with addition terms defined here:</t>
        <ul spacing="normal">
          <li>
            <t>legacy name servers: An authoritative server that does not support the DELEG record.</t>
          </li>
          <li>
            <t>legacy resolvers: A resolver that does not support the DELEG record.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="deleg-record-type">
      <name>DELEG Record Type</name>
      <t>The DELEG record uses a new resource record type, whose contents are identical to the SVCB record defined in <xref target="RFC9460"/>. For extensions SVCB and DELEG use Service Parameter Keys (SvcParamKeys) and new SvcParamKeys that might be needed also will use the existing IANA Registry.</t>
      <section anchor="differences-from-svcb">
        <name>Differences from SVCB</name>
        <ul spacing="normal">
          <li>
            <t>DELEG can only have two priorities 0 indicating INCLUDE and 1 indicating a DIRECT delegation. These terms MUST be used in the presentation format of the DELEG record.</t>
          </li>
          <li>
            <t>INCLUDE and DIRECT delegation can be mixed within an RRSet</t>
          </li>
          <li>
            <t>The final INCLUDE target is an SVCB record, though there can be further indirection using CNAME or AliasMode SVCB records.</t>
          </li>
          <li>
            <t>There can be multiple INCLUDE DELEG records, but further indirections through SVCB records have to comply with <xref target="RFC9460"/> in that there can be only one AliasMode SVCB record per name.</t>
          </li>
          <li>
            <t>In order to not allow unbounded indirection of DELEG records the maximum number of indirections, CNAME or AliasMode SVCB is 4.</t>
          </li>
          <li>
            <t>The SVCB IPv4hint and IPv6hint parameters keep their key values of 4 and 6, but the presentation format with DELEG MUST be Glue4 and Glue6.</t>
          </li>
          <li>
            <t>Glue4 and Glue6 records when present MUST be used to connect to the delegated name server.</t>
          </li>
          <li>
            <t>The target of a DELEG record MUST NOT be '.' and for INCLUDE must be outside of the delegated domain and for DIRECT in domain delegations below the zone cut.</t>
          </li>
        </ul>
      </section>
      <section anchor="use-of-deleg-record">
        <name>Use of DELEG record</name>
        <t>The DELEG record creates a zone cut similar to the NS record so all data at or below the zone cut has to be resolved using the name servers defined in the DELEG record.</t>
        <t>A DELEG RRset MAY be present at a delegation point.  The DELEG RRset MAY contain multiple records. DELEG RRsets MUST NOT appear at a zone's apex.</t>
        <t>A DELEG RRset MAY be present with or without NS or DS RRsets at the delegation point.</t>
        <t>An authoritative server that is DELEG aware MUST put all DELEG resource records for the delegation into the authority section when the resolver has signalled DELEG support. It SHOULD NOT supply DELEG records in the response when receiving a request without the DE bit.</t>
        <t>If the delegation does not have DELEG records the authoritative server MUST send the NS records and, if the zone is DNSSEC signed, prove the absence of the DELEG RRSet.</t>
        <t>A resolver that is DELEG aware MUST signal its support by sending the DE bit when iterating and MUST use the DELEG records in the referral response.</t>
      </section>
      <section anchor="signaling-deleg-support">
        <name>Signaling DELEG support</name>
        <t>For a long time there will be both DELEG and NS needed for delegation. As both methods should be configured to get to a proper resolution it is not necessary to send both in a referral response. We therefore purpose an EDNS flag to be use similar to the DO Bit for DNSSEC to be used to signal that the sender understands DELEG and does not need NS or glue information in the referral.</t>
        <t>This bit is referred to as the "DELEG" (DE) bit.  In the context of the EDNS0 OPT meta-RR, the DE bit is the TBD of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows (to be updated when assigned):</t>
        <artwork><![CDATA[
            +0 (MSB)                +1 (LSB)
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  0: |   EXTENDED-RCODE      |       VERSION         |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  2: |DO|CO|DE|              Z                       |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork>
        <t>Setting the DE bit to one in a query indicates to the server that the resolver is able to accept delegations using DELEG only. The DE bit cleared (set to zero) indicates the resolver is unprepared to handle DELEG and hence can only be served NS, DS and glue in a delegation response. The DE bit of the query MUST be copied in the response.</t>
      </section>
      <section anchor="dnssec">
        <name>DNSSEC</name>
        <t>As the DELEG record is authoritative in the parent zone of a zone cut similar to DS it has to be signed in the parent zone.</t>
        <t>In order for the validator to understand that the delegation uses DELEG this draft introduces a new DNSKEY flag TBD. When this flag is set for the key that signs the DS or DELEG record, usually the zone signing key (ZSK), and the requester has signalled that it understands DELEG an authenticated denial of existence MUST be send with the referral response, so that a DELEG aware validator can prove the existence or absence of a DELEG record and detect a downgrade attack.</t>
        <t>A Validating Stub Resolver that is DELEG aware has to use a Security-Aware Resolver that is DELEG aware and if it is behind a forwarder this has to be security and DELEG aware as well.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to allocate the DELEG RR in the Resource Record (RR) TYPEs registry, with the meaning of "enchanced delegation information" and referencing this document.</t>
      <t>IANA is requested to assign a new bit in the DNSKEY RR Flags registry (<xref target="RFC4034"/>) for the DELEG bit (N), with the descripion "DELEG" and referencing this document.</t>
      <t>IANA is requested to assign a bit from the EDNS Header Flags registry (<xref target="RFC6891"/>), with the abbreviation DE, the description "DELEG enabled" and referencing this document.</t>
      <t>For the RDATA parameters to a DELEG RR, the DNS Service Bindings (SVCB) registry (<xref target="RFC9460"/>) is used.  This document requests no new assignments to that registry, though it is expected that future DELEG work will.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/std13">
          <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034">
            <front>
              <title>Domain names - concepts and facilities</title>
              <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
              <date month="November" year="1987"/>
              <abstract>
                <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="13"/>
            <seriesInfo name="RFC" value="1034"/>
            <seriesInfo name="DOI" value="10.17487/RFC1034"/>
          </reference>
          <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
            <front>
              <title>Domain names - implementation and specification</title>
              <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
              <date month="November" year="1987"/>
              <abstract>
                <t>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.</t>
              </abstract>
            </front>
            <seriesInfo name="STD" value="13"/>
            <seriesInfo name="RFC" value="1035"/>
            <seriesInfo name="DOI" value="10.17487/RFC1035"/>
          </reference>
        </referencegroup>
        <reference anchor="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>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9460"/>
          <seriesInfo name="DOI" value="10.17487/RFC9460"/>
        </reference>
        <reference anchor="RFC4034">
          <front>
            <title>Resource Records for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>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.</t>
              <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4034"/>
          <seriesInfo name="DOI" value="10.17487/RFC4034"/>
        </reference>
        <reference anchor="RFC6891">
          <front>
            <title>Extension Mechanisms for DNS (EDNS(0))</title>
            <author fullname="J. Damas" initials="J." surname="Damas"/>
            <author fullname="M. Graff" initials="M." surname="Graff"/>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <date month="April" year="2013"/>
            <abstract>
              <t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t>
              <t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="75"/>
          <seriesInfo name="RFC" value="6891"/>
          <seriesInfo name="DOI" value="10.17487/RFC6891"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="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">
          <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>
        <referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/bcp219">
          <reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rfc9499">
            <front>
              <title>DNS Terminology</title>
              <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
              <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
              <date month="March" year="2024"/>
              <abstract>
                <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
                <t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="219"/>
            <seriesInfo name="RFC" value="9499"/>
            <seriesInfo name="DOI" value="10.17487/RFC9499"/>
          </reference>
        </referencegroup>
        <reference anchor="I-D.tapril-ns2">
          <front>
            <title>Parameterized Nameserver Delegation with NS2 and NS2T</title>
            <author fullname="Tim April" initials="T." surname="April">
              <organization>Akamai Technologies</organization>
            </author>
            <date day="13" month="July" year="2020"/>
            <abstract>
              <t>   Within the DNS, there is no mechanism for authoritative servers to
   advertise which transport methods they are capable of.  If secure
   transport methods are adopted by authoritative operators, transport
   signaling would be required to negotiate how authoritative servers
   would be contacted by resolvers.  This document provides two new
   Resource Record Types, NS2 and NS2T, to facilitate this negotiation
   by allowing zone owners to signal how the authoritative nameserver(s)
   for their zone(s) may accept queries.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tapril-ns2-01"/>
        </reference>
      </references>
    </references>
    <?line 203?>

<section anchor="examples">
      <name>Examples</name>
      <t>The following example shows an excerpt from a signed root zone. It shows the delegation point for "example." and "test."</t>
      <t>The "example." delegation has DELEG and NS records. The "test." delegation has DELEG but no NS records.</t>
      <artwork><![CDATA[
example.   300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
                        Glue6=2001:DB8::1 )
example.   300 IN DELEG 0 ns2.example.net.
example.   300 IN DELEG 0 ns3.example.org.
example.   300 IN RRSIG DELEG 13 4 300 20250214164848 (
                        20250207134348 21261 . HyDHYVT5KcqWc7J..= )
example.   300 IN NS    a.example.
example.   300 IN NS    b.example.net.
example.   300 IN NS    c.example.org.
example.   300 IN DS    65163 13 2 5F86F2F3AE2B02... 
example.   300 IN RRSIG DS 13 4 300 20250214164848 (
                        20250207134348 21261 . O0k558jHhyrC21J..= )
example.   300 IN NSEC  a.example. NS DS RRSIG NSEC DELEG
example.   300 IN RRSIG NSEC 13 4 300 20250214164848 (
                        20250207134348 21261 . 1Kl8vab96gG21Aa..= )
a.example. 300 IN A     192.0.2.1
a.example. 300 IN AAAA  2001:DB8::1
]]></artwork>
      <t>The "test." delegation point has a DELEG record and no NS record.</t>
      <artwork><![CDATA[
test.      300 IN DELEG 0 ns2.example.net
test.      300 IN RRSIG DELEG 13 4 300 20250214164848 (
                        20250207134348 21261 . 98Aac9f7A1Ac26Q..= ) 
test.      300 IN NSEC  a.test. RRSIG NSEC DELEG
test.      300 IN RRSIG NSEC 13 4 300  20250214164848 (
                        20250207134348 21261 . kj7YY5tr9h7UqlK..= )
]]></artwork>
      <section anchor="responses">
        <name>Responses</name>
        <t>The following sections show referral examples:</t>
      </section>
      <section anchor="do-bit-clear-de-bit-clear">
        <name>DO bit clear, DE bit clear</name>
        <section anchor="query-for-fooexample">
          <name>Query for foo.example</name>
          <t>;; Header: QR RCODE=0<br/>
;;</t>
          <t>;; Question<br/>
foo.example.  IN MX</t>
          <t>;; Answer<br/>
;; (empty)</t>
          <t>;; Authority<br/>
example.   300 IN NS    a.example.<br/>
example.   300 IN NS    b.example.net.<br/>
example.   300 IN NS    c.example.org.</t>
          <t>;; Additional <br/>
a.example. 300 IN A     192.0.2.1<br/>
a.example. 300 IN AAAA  2001:DB8::1</t>
        </section>
        <section anchor="query-for-footest">
          <name>Query for foo.test</name>
          <t>;; Header: QR AA RCODE=3
;;</t>
          <t>;; Question<br/>
foo.test.   IN MX</t>
          <t>;; Answer<br/>
;; (empty)</t>
          <t>;; Authority<br/>
.   300 IN SOA ...</t>
          <t>;; Additional <br/>
;; (empty)</t>
        </section>
      </section>
      <section anchor="do-bit-set-de-bit-clear">
        <name>DO bit set, DE bit clear</name>
        <section anchor="query-for-fooexample-1">
          <name>Query for foo.example</name>
          <artwork><![CDATA[
;; Header: QR DO RCODE=0  
;;

;; Question  
foo.example.   IN MX

;; Answer  
;; (empty)

;; Authority  
    
example.   300 IN NS    a.example.  
example.   300 IN NS    b.example.net.  
example.   300 IN NS    c.example.org.  
example.   300 IN DS    65163 13 2 5F86F2F3AE2B02...  
example.   300 IN RRSIG DS 13 4 300 20250214164848 (  
                        20250207134348 21261 . O0k558jHhyrC21J..= )  
;; Additional  
a.example. 300 IN A     192.0.2.1  
a.example. 300 IN AAAA  2001:DB8::1
]]></artwork>
        </section>
        <section anchor="query-for-footest-1">
          <name>Query for foo.test</name>
          <artwork><![CDATA[
;; Header: QR DO AA RCODE=3  
;;
    
;; Question  
foo.test.      IN MX 
    
;; Answer  
;; (empty)

;; Authority  
.          300 IN SOA ...
.          300 IN RRSIG SOA ...
.          300 IN NSEC  aaa NS SOA RRSIG NSEC DNSKEY ZONEMD
.          300 IN RRSIG NSEC 13 4 300  
test.      300 IN NSEC  a.test. RRSIG NSEC DELEG
test.      300 IN RRSIG NSEC 13 4 300  20250214164848 (
                        20250207134348 21261 . aBFYask;djf7UqlK..= )

;; Additional   
;; (empty)    
]]></artwork>
        </section>
      </section>
      <section anchor="do-bit-clear-de-bit-set">
        <name>DO bit clear, DE bit set</name>
        <section anchor="query-for-fooexample-2">
          <name>Query for foo.example</name>
          <artwork><![CDATA[
;; Header: QR DE RCODE=0  
;;

;; Question  
foo.example.  IN MX

;; Answer  
;; (empty)

;; Authority  
example.   300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
                        Glue6=2001:DB8::1 )
example.   300 IN DELEG 0 ns2.example.net.
example.   300 IN DELEG 0 ns3.example.org.

;; Additional   
;; (empty)  
]]></artwork>
        </section>
        <section anchor="query-for-footest-2">
          <name>Query for foo.test</name>
          <artwork><![CDATA[
;; Header: QR AA RCODE=0
;;
    
;; Question  
foo.test.   IN MX 
    
;; Answer  
;; (empty)

;; Authority  
test.      300 IN DELEG 0 ns2.example.net

;; Additional   
;; (empty)    
]]></artwork>
        </section>
      </section>
      <section anchor="do-bit-set-de-bit-set">
        <name>DO bit set, DE bit set</name>
        <section anchor="query-for-fooexample-3">
          <name>Query for foo.example</name>
          <artwork><![CDATA[
;; Header: QR DO DE RCODE=0  
;;

;; Question  
foo.example.  IN MX

;; Answer  
;; (empty)

;; Authority  
    
example.   300 IN DELEG 1 a.example. Glue4=192.0.2.1 (
                        Glue6=2001:DB8::1 )
example.   300 IN DELEG 0 ns2.example.net.
example.   300 IN DELEG 0 ns3.example.org.
example.   300 IN RRSIG DELEG 13 4 300 20250214164848 (
                        20250207134348 21261 . HyDHYVT5KcqWc7J..= )
example.   300 IN DS    65163 13 2 5F86F2F3AE2B02...  
example.   300 IN RRSIG DS 13 4 300 20250214164848 (  
                        20250207134348 21261 . O0k558jHhyrC21J..= )  

;; Additional  
a.example. 300 IN A     192.0.2.1  
a.example. 300 IN AAAA  2001:DB8::1  
]]></artwork>
        </section>
        <section anchor="query-for-footest-3">
          <name>Query for foo.test</name>
          <artwork><![CDATA[
;; Header: QR DO DE AA RCODE=3  
;;
    
;; Question  
foo.test.      IN MX 
    
;; Answer  
;; (empty)

;; Authority  
.          300 IN SOA ...
.          300 IN RRSIG SOA ...
.          300 IN NSEC  aaa NS SOA RRSIG NSEC DNSKEY ZONEMD
.          300 IN RRSIG NSEC 13 4 300  
test.      300 IN NSEC  a.test. RRSIG NSEC DELEG
test.      300 IN RRSIG NSEC 13 4 300  20250214164848 (
                        20250207134348 21261 . aBFYask;djf7UqlK..= )

;; Additional   
;; (empty)    
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="acknowledgments-unnumbered">
      <name>Acknowledgments {:unnumbered}</name>
      <t>This document is heavily based on past work done by Tim April in 
<xref target="I-D.tapril-ns2"/> and thus extends the thanks to the people helping on this which are:
John Levine, Erik Nygren, Jon Reed, Ben Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, Gordon Marx and Brian Wellington.</t>
    </section>
    <section anchor="todo">
      <name>TODO</name>
      <dl>
        <dt>RFC EDITOR:</dt>
        <dd>
          <t>PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.</t>
        </dd>
      </dl>
      <ul spacing="normal">
        <li>
          <t>Write a security considerations section</t>
        </li>
        <li>
          <t>Change the parameters form temporary to permanent once IANA assigned. Temporary use:
          </t>
          <ul spacing="normal">
            <li>
              <t>DELEG QType code is 65432</t>
            </li>
            <li>
              <t>DELEG EDNS Flag Bit is 3</t>
            </li>
            <li>
              <t>DELEG DNSKEY Flag Bit is 0</t>
            </li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="change-log">
      <name>Change Log</name>
      <dl>
        <dt>RFC EDITOR:</dt>
        <dd>
          <t>PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION.</t>
        </dd>
      </dl>
      <section anchor="since-draft-wesplaap-deleg-00">
        <name>since draft-wesplaap-deleg-00</name>
        <ul spacing="normal">
          <li>
            <t>Clarified SVCB priority behaviour</t>
          </li>
          <li>
            <t>Added section on differences to draft-homburg-deleg-incremental-deleg</t>
          </li>
        </ul>
      </section>
      <section anchor="since-draft-wesplaap-deleg-01">
        <name>since draft-wesplaap-deleg-01</name>
        <ul spacing="normal">
          <li>
            <t>Reorganised and streamlined the draft to the bare mininum for DELEG as an NS replacement</t>
          </li>
          <li>
            <t>Defined codepoints for temporary testing</t>
          </li>
          <li>
            <t>Added examples</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="C." surname="Elmerot" fullname="Christian Elmerot">
        <organization>Cloudflare</organization>
        <address>
          <email>christian@elmerot.se</email>
        </address>
      </contact>
      <contact initials="E." surname="Lewis" fullname="Edward Lewis">
        <organization>ICANN</organization>
        <address>
          <email>edward.lewis@icann.org</email>
        </address>
      </contact>
      <contact initials="R." surname="Arends" fullname="Roy Arends">
        <organization>ICANN</organization>
        <address>
          <email>roy.arends@icann.org</email>
        </address>
      </contact>
      <contact initials="S." surname="Huque" fullname="Shumon Huque">
        <organization>Salesforce</organization>
        <address>
          <email>shuque@gmail.com</email>
        </address>
      </contact>
      <contact initials="K." surname="Darilion" fullname="Klaus Darilion">
        <organization>nic.at</organization>
        <address>
          <email>klaus.darilion@nic.at</email>
        </address>
      </contact>
      <contact initials="L." surname="Peltan" fullname="Libor Peltan">
        <organization>CZ.nic</organization>
        <address>
          <email>libor.peltan@nic.cz</email>
        </address>
      </contact>
      <contact initials="V." surname="Čunát" fullname="Vladimír Čunát">
        <organization>CZ.nic</organization>
        <address>
          <email>vladimir.cunat@nic.cz</email>
        </address>
      </contact>
      <contact initials="S." surname="Kerr" fullname="Shane Kerr">
        <organization>NS1</organization>
        <address>
          <email>shane@time-travellers.org</email>
        </address>
      </contact>
      <contact initials="D." surname="Blacka" fullname="David Blacka">
        <organization>Verisign</organization>
        <address>
          <email>davidb@verisign.com</email>
        </address>
      </contact>
      <contact initials="G." surname="Michaelson" fullname="George Michaelson">
        <organization>APNIC</organization>
        <address>
          <email>ggm@algebras.org</email>
        </address>
      </contact>
      <contact initials="B." surname="Schwartz" fullname="Ben Schwartz">
        <organization>Meta</organization>
        <address>
          <email>bemasc@meta.com</email>
        </address>
      </contact>
      <contact initials="J." surname="Včelák" fullname="Jan Včelák">
        <organization>NS1</organization>
        <address>
          <email>jvcelak@ns1.com</email>
        </address>
      </contact>
      <contact initials="P. van" surname="Dijk" fullname="Peter van Dijk">
        <organization>PowerDNS</organization>
        <address>
          <email>peter.van.dijk@powerdns.com</email>
        </address>
      </contact>
      <contact initials="P." surname="Homburg" fullname="Philip Homburg">
        <organization>NLnet Labs</organization>
        <address>
          <email>philip@nlnetlabs.nl</email>
        </address>
      </contact>
      <contact initials="E." surname="Nygren" fullname="Erik Nygren">
        <organization>Akamai Technologies</organization>
        <address>
          <email>erik+ietf@nygren.org</email>
        </address>
      </contact>
      <contact initials="V." surname="Adhvaryu" fullname="Vandan Adhvaryu">
        <organization>Team Internet</organization>
        <address>
          <email>vandan@adhvaryu.uk</email>
        </address>
      </contact>
      <contact initials="M." surname="Bretelle" fullname="Manu Bretelle">
        <organization>Meta</organization>
        <address>
          <email>chantr4@gmail.com</email>
        </address>
      </contact>
      <contact initials="B." surname="Halley" fullname="Bob Halley">
        <organization>Cloudflare</organization>
        <address>
          <email>bhalley@cloudflare.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHFKtGcAA+1b/XLbOJL/n0+Bdf4Ye0dmSbLjJJqaGsuSnHjir0hKspnd
qyuIhCRG/ApIWlESv8HeO9w+wD3F7L3XdjdAEpQo25nNXd1crWsmlkigu9H9
6y8A3t/ft1Iv9UWHDT6mIky8iS9YX/hixlMvCtk0kqx/ObL4ZCLFTYf1B+eD
55YbOSEPYJIr+TTdX4ok9jmP912cuO/zVCSp5cKvDvvc744Ht5YDX2aRXHVY
krpWFuPLpMNazYPHluXFssNSmSVpu9l81mxbSTYJvCQBAdJVDETOBuNTi0vB
4WOYChmK1FqI1TKSbvlkv4/CWFaS8tD9d+5HIcxcicSKvQ77cxo5DZZEMpVi
msCnVYAf/s2yeJbOI9mx9i0GP14IUo1t1o2l59MTtdCxFxjPIjnjofeJVNRh
z6No5osGOz/v0VsRcM/vME+k0+OU4yQbBTYYXNv//Z8x//t/iIXB4lqkklWe
V9mcjSrk4yTmjlgce4ljw0CT/NB+KyZCGrSH3J+y8mGVcHfBgSQbC2ceRn40
80BnBiO5xHnHnEbZThSYrPr2OV9KETrC4NbnN57LeqzyqspzxH2RALj0S80q
hafHrkvrsRywvvQmWVpaR5HvzaWXpB4P2cAPhIzSGvo9P8rcqQ+YMek7+cxj
oWbaiaiQHrhLLl12LpZeUmeCXvfy0iQoaLzt4/hjz+FhaNhCqz5asS6owX0Q
QRmtbE6jt5AbzbMA/PJF9iF7uF6TOQ4/nuE3w4KK4kufZwnYDHAKJGpohp5j
89Skt8AptqunHOsBJtFzbwKR41r44Ix15vnFhkkmSR8n2DFNIILOpwrBNz53
veDX/5Ls73/Nwl//Vmv0Dao3NMuTtpOFPK2jO5rzULCXQtZ5xuWoVVUjjD1O
vUDsp5LfCN8XMtmwkEL/ic+dBa+h+UYABr1ZaBJ2ccrk+Ea/2jDRcwE0BLvw
nDkXflJrpe715VklQMxmwTH3Z2Ii+aaQJyJkI2cO6E0/1RC7ECk3aU3gd+Ic
B/B4Q7ifwRHfQMzyf/1bXdha0+H7G0f4fHEcJq0NShABhWQ3QK/vva+jdR0t
hcR0ZMZBnGTDJNuFSccxDnHDZJP4HMAasxdRMMlAGTWCnkOUhpg1qUS/mKYd
hz689OGdHfrViCG9BbtczcBnvz60gr0X31OeCInChpneQCoDdXTd+Q2Xq6yG
w1jwoEyKJvRp6jHXU+1sUaF8wcOMnUhQHqD4AQgA5EE4PtwSQ06iCXvBgdLq
wbF4Mqfxx07xlqha+/v7DPQMDuakVpe5ZS3ihSydQ3USAYGQXQJjNlolqQjY
LmBij3kJ4ywQKKmXBDCWp0yEHCqahInp1HM8EaYM1MJcyAKUWoTLAh7ymQjw
VTRVDC5HtCxKsDY7S4HzTeTfAJlcmnDGVN3gpSsWgd8yKFlcEixhacSSWDge
cCRaiZAwImE3HgdvYFI4ULdADQLrj5ZICosszuaekFw6c4j7PlRJMnPSTIqq
vDgaRZQgXITVGoATJEACyDuF/3FIv2RjW1Y3LNkyzKpKSiAzj5IUV5qvnFZN
0hJJfKRXDIoyVNINgSd3kDkgWs0GZRvTAyjmIGqg5A7qB+ancxllszmLgKws
7ZTYbDwH00FNmZEVYhnFUSLQmKFYMmHUpeUysC5sqGq0QbIaOEGxS+so5Srb
2Ow0I6XmzEgNIYNMy7JEwBcQxEBQRE+563pIGMzihUAuUGz4JMrSbTois+E7
h8d8YigqFwxo3JgKT+7UOHlF4Lku+Kr1CP1dRi4ABBO2dbbVLz5//sNo3G8d
3N42TIAuPViomqQeEacCgCsGzghLdT2HxJisDO0qeGuRlwDWOY2uLksvxZMs
hooblWUCTGEIrG5aNFEQciMyQgP0BtHBrfiLhm6BWtKnocGGlgecA70VBQXT
wTcAE/C7jDT0TCNizLiBeIRRAido58L5Url+AqVJ4KEe4DWIEAonzUdWV51r
heLB6/41YWDcuyYlsMcHGuhEruTOJlxKT3tcGaY8w8S0TnAF1Faap5KVzSwL
daj9xVXeYDoIfA6Ei8AjYMNAWGWA9oSPUHFgqDDcK+YSlJniEmB9uf2rCMYl
1fsDIgzBkLCZnwllTV7oEsLTipxpE+WFq+b6rmpVORJUqFgZwXAN3Bir5BQe
ukX0MkJAwBe4OA+iSZSo1cGSbrjvYeOJkdccbSx8VwELmdIyNPj2yGfQAKNB
z0a9mxErCv0VFIfRMgFsLrUdMKZAAMwSkhnckbsoKEYjaE1nSnIjIRC8oMVF
8QzhakJWGa2Eab4yblE6iNArXagCHBBgCnSBCIJvIXIUUzKJMMyi9+vATesE
BtC3yVVMsJc8TBDCsO5Hj6DgkIGnEKjwB404W5IH71y8Ho13Guo3u7yiz8PB
q9dnw0EfP49edM/Piw9qhAVfrl6f6/f4qZzZu7q4GFz21WR4ytYeXXTfwS8w
lrVzdT0+u7rsnu8ogJjmwfgE65xgTAMjx1j0uAhUVyQOpFUFqr/8xToBX20d
QtT8aXjaa7daz25v9ZenrSeH8GUJyYL4KZOrr2AGiJhxLDiGFguxBS4D8PUx
xycEDAhakAMROKX2wO4zaB7zlF4TvqEeApNNZYSR/CeQro0iNbSNtBdCRJAB
rmXqoXsgn45l/ZEhgJyVaVto16EUqItZeewFbmEETpXFFLJILCOo2CXZ3K+R
ZunkDyUDKUw9GCrojyFYKTBVYlhWVgHIIoOutpr/l5AKCM4pOQalLRc+Ugml
Y/ToTe8kn5UrCfSs7Prs8Kh5ews+hrFXuRKmOJqDZlbioLONQFEe8L/OYwX0
jCuIF6Mbhx7htz2ag+KaT5VWAm82p4ooFMJF+EEbB4YEsJSujHsTgIaz7mUX
NDPDoo+iPHhd35tOBW2maECgiGjmMtgQJOccE98yggjvoZUxZjfzWE7EL3vn
r/sDkrRlvuCsD27aG1diD5gEpSOEkVOXEU1FYbAL6LvYK4RUUFTRa8AxGW9w
yqNl4H0E4ro+gUfD4Qi6mj9SrQCmA6vmZFIOHbFKF6FpY/RHKjMx1Yuc7jST
OvW7nhQqqWYJLrt32b0YYFTu+h5PLiK3gpjEVsxLSkHmp14M4TYXxFwnODwU
6XXckqL8Nalrc2FdEcQYUNCxTWQqPfO0uhqydBSKepmhI5bk9qR1wIV00TUj
8knqOVgWQu0auhV1gNkqSyEjBvyjF2QBC7NgAkRgjLmmxlbtgVkOterUg7Pr
m0OwqWq/4MsRfTES70KIWNeMmFAgVWeqwDukKUdKs9swp7IziZ/D9DkQUHPx
0xFKs/aoWCnG8ZxsFeabJV+1OtfxM1+qBiWW+dVIlidEJPyd/R3JgFk6B1He
LkFHUVPRADNdp+fztAPBE/3CLNAnAm2M8z8hSJxMZ+7XiVi3ck3QVTUIxt18
NpQqAVTIMldBWbJACKNSiqecoefLGt6A8USnX50nXO16eUNQFM5GeN6IIBAG
u3nSGCagZMj9SDM3G1WbZk0XAcDyLmNtWt5IFL6cO7s5MimNppM7scBlfQfa
icVH+x6RCJSRKqmwVQS9oelGOX2erpetWmhq2bfnaXAuxZUvMeORmHFGvl3o
rJItN3pLtZuy1sRACatDAfmD2QmRDbH+Vk2ZYqLTO1XtZeFGjyE8VWOJV9DD
bQuhOMBL4d2o3CPFB/D3tNCVsj+beIjds436vqgxKIBuxq1a5ZGiwDJuFcVU
7TeYNy1hixqmUl83HQ1qmFSa5pME03A1zVGeIjxUa6E6Uyk9Qm+SFBXSZEVy
FaUgLVwpCTpPqRN0qONIXjBsUTHUCRLo57rWBcSIuNLmkGk9yzql/RFqSXBn
W2caqkwAy5OoCKzIH3fGVP1S3XOxWTdRYyGczyOXqt7Md5EEeNvUm2VShVOM
j9R0YNsKaiJ9ZQqRpC+0KgRc6Nq5XKnNBmBMtDEA1i3wrZZ6ij1PnElsh7Es
GGDDPPX5TMcfVNxaLOtfsRPgq4850eLFUBJXGyvPwSQMSJ3hv3TQmBjaKVCJ
OtLuTl1kZcehaqe8mZyo1avHijdXWN4hBjtstz/YI4dgTO/4UOH7sai4cLlN
Bo0QGoHvD4cNE02eojY+6efjd6jiRWMOe1e6MkNtJTvr2zY1lIsNSuqkphHW
FVAOa+3R+a6rEMwT5UR70JawtZ/vm2z3YnSyt/G8xXbP4Xk54fv9/a/7T09t
dtgX+DX405i6xn21VPr5okm/GQxH0DsWrL7881zbwLV/9aV39aU/+MIqP7+s
r/VbcLUg/KRr4QNMQbEMnQaCKzhTvqWT5Og3s0ol3mNZrTdNuOOIOK0UGCp9
K9xjLWrrLEtsHR9yJdh+N1Ge/knIaM9kvcYnCyFfxlxjfg4g9IXhU3MKtkV/
M9FCo3s1MJcWOzW0TiNFlOHBEE7jWakjr/ScKPbKqqOYZ6nGi6ICRPZkI+Zu
7lVV96YolVAtWFdJgeyeWRzVbm/hRAzgRRmfJ3K9lRURqTIalaY0NEFttBJc
bYzgPYlig7FosWGlLwfvVLyEKAFhVZUBMIOewW80aS4BVunEDQXXylEFjqGi
BjDPoGhYlbkVhyN8cP7uL6OXe41irzwvAqrVhkqkaW3MJf2rhp+qZBF6EK1B
59RME3RyK1MaoZKsNk3i5ZB809JM2aWiEYNlGVAywPxZ1gRrhT+lBehwHCpP
o2U4kxz3/dKUOwsqGN4oBqiSUZpNoPG/o4DQcKFTCTYSToZ1236X3t05EeWA
CkflgYmA7gtkQ1vi/QWa4yUmGDVpYxNE04FuSfg+beHQPkUPj6FcqlHgEyAV
H1IiI1vqTAbZgfaSzYoph/owL1b1ZtDucLjHxu+uB0hEbYI0SsMFghN8QNU7
oPO52t+s1LVFrt0h8cnUMFSFR2Nj0N4mLSUs7RWUOsP8XBAdBCQ/xSxZSMd2
P3/+A7Tsh82Dw9vbvcJD1EKRwO7lnrEEte0Yo7B5bv/n5EQWtCmU52r2QnC0
ar2cR0+ftUBOQyJ1u8tTCuwPGqaYaSmnPk1175f3VKtg2O+Ou2sHC7xAQKM4
bs131048qoJxX+1ND8qCddHVrggd9WKFRv2dudWr9YNVGFlPqUif9Gn/LkGl
d4qUU4iPMXhpHm+matNdSbqM5IIqYuCnDqgn4L3oAmzwkQfQQSaqkVZlkDpW
oef6VAD30z86QsbaTjyP9jKK8iAPXZQaXNcTEqZ2NFFb6X8Hb9nZO4qz8c6Y
iw5dKd6LRpfmKAL1E3C3BZRYOUim03vNBz4eNJvs7FKPbzFuF+9oo+XH1rO2
3bTbNtRyG4Wf+UObMT+2m81Wp3/ytNNpsb07WTVZmLQLZiE2XvcNPyiGR3K2
bTg0cWfP8+UcsEN63m62HzfbrcPW0eHTw6f3rEQNbj5pHRwewOB2q33UYjZ7
seq/ePdm/Pil8+Gt8+Rn2/5x6wpB3/BTqvLOYZOHKEENdR6igD4NPXrcOjpA
BbTZ49OnR6ft04PuoH3SbNs2lCJ3qm70bfV21Vw8fvz0/Yv5SvbarXv0Bq2b
CUFYNu20oFz0Ut1cvUt8GvZNF9B66T+94ZNnR7Pn7VaXlwswBNUidIlO4TLb
RsEPcitcRXv/piersIH+XFORmI6twED/EBW1oLsdbsvo/zEHeva0y51n0yfd
VtdpH70iPW4TOUeCelMLgG2SVwHwTSRfvH/y7t3jVD6bP3n9wX9ZIgB7i6Gu
PTeyR5IfGmBGKGtVbYGkozqTq7LfalS6L3z9iL2iJgcTxzSKcuuVa7B++EGX
CR32aqi2AH5s0nMrf/8KkymiiVkGDdyAuGQXfyqGdcNkCdUGfd4VQZyu9ix6
XuwsMuv+UHfHoGqgu2NgNcxhtkYxyvsK8ORe16sfs+54jNVpmS6+r2kWJirl
Htyh2hySpFj2VZo1lDC66jKI0jWrLucX3q6gYCAJuruH40hVA9WVAp0SRup1
yam6ZnxShZSJKT2+WL3+nmugMsbQRAFt/OdBgLtr4Abo7hq8Abz6wQ/IsL89
xRoa+IoIVZdkDfUaKHpY5to+biN3lVDc5km1GCsdqgqze6BmRH3Dyx6Ct21Y
s0vlrjlg/VtlwrvH6PTF6WYQDjUzmGpAf7m6HFz07+Sxlsl+F6mSn5y+48ni
B/f91MiVdUBcN1CJo615EWLbV0ezwWY0e1AkU4Hst4Lq/0WD9TCrfa3vF47f
/A1u/418/uE18lchV6F3SzK+D7w12L2qhe89qqqt7+7RU2XMw3Px7xDT9cP/
L2wa/H6qiv+NsuKOyrwA5FaX+Vdt8a/agtXXFsqcj1jXWYTR0hfuTO0rf+5k
obofJ9zb9avheKoi+I2HR5cc7xTQdXO86IJ7yi4eiE1W5V8X41GD9fnzT2f7
fVv96fA+hK3b2/IWvDqzV7vE6ZyHi+IwNxYR7jjPhR/TAYk+uyv+RqNj/RzN
Q3YubrxQNMw/XGuwn2H0UOBFF/zDwJfczRYNdsGTeRR9YBfZnHsBDeMJDLyI
pOAZfBNSRi5764kk4PD2xMODvrEn4Bt8fR5JF0dz+ZHEP5H4J7tvhY+3UNIo
pDOk8VX/yrKGpz026J+Nr4Ydq8OuzwfdEWSvwcXVmwEbv8D/zwCwgx5e8WbX
w7OrIUxk169Pzs96XXxo41XYt+A+eC5WHF45lbOpfFcFRvZAcTORH7TmZxN4
bgSgDOJI6qsnsZCwFnXF3xHqwCu/zmCzcTE0S0C7jOW3cV/hfWbg7tJNoqPH
hwdt4y0d0ODJDN08gQEHxkvthubrJupJS3wezb6NtiA+Jh6uqfYv+JtN1GfP
59Kb4tE4XeHUN4rxDH4OiI4yiYPAd2BAfnMMr2YZN5VBhYr+XP3VpSYPjCX9
xR331ZN75Wkhq6FQf1eIboSASlLAYeDTlUE6NKFzbe0NEzytDPDP4TL1BxH6
HIQOY2jzExg4JAXeotY3D9FmtHOqr8yVYBB0N7tYcL4VZ/0DbcrCvEJBAAA=

-->

</rfc>