DNS Delegation                                                P. Homburg
Internet-Draft                                                NLnet Labs
Intended status: Standards Track                             T. Wicinski
Expires: 12 July 2025                                 Cox Communications
                                                           J. V. Zutphen
                                                 University of Amsterdam
                                                               W. Toorop
                                                              NLnet Labs
                                                          8 January 2025


         Incrementally Deployable Extensible Delegation for DNS
                draft-homburg-deleg-incremental-deleg-01

Abstract

   This document proposes a mechanism for extensible delegations in the
   DNS.  The mechanism realizes delegations with resource record sets
   placed below a _deleg label in the apex of the delegating zone.  This
   authoritative delegation point can be aliased to other names using
   CNAME and DNAME.  This document proposes a new DNS resource record
   type, DELEG, which is based on the SVCB and inherits extensibility
   from it.

   Support in recursive resolvers suffices for the mechanism to be fully
   functional.  The number of subsequent interactions between the
   recursive resolver and the authoritative name servers is comparable
   with those for DNS Query Name Minimisation.  Additionally, but not
   required, support in the authoritative name servers enables optimized
   behavior with reduced (simultaneous) queries.  None, mixed or full
   deployment of the mechanism on authoritative name servers are all
   fully functional, allowing for the mechanism to be incrementally
   deployed.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-homburg-deleg-incremental-
   deleg/.

   Discussion of this document takes place on the deleg Working Group
   mailing list (mailto:dd@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/dd/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/dd/.





Homburg, et al.           Expires 12 July 2025                  [Page 1]

Internet-Draft              incremental-deleg               January 2025


   Source for this draft and an issue tracker can be found at
   https://github.com/NLnetLabs/incremental-deleg.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 12 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Signaling capabilities of the authoritative name
           servers . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Outsourcing operation of the delegation . . . . . . . . .   4
     1.3.  DNSSEC protection of the delegation . . . . . . . . . . .   4
     1.4.  Maximize ease of deployment . . . . . . . . . . . . . . .   5
     1.5.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  The DELEG resource record type  . . . . . . . . . . . . . . .   6
   3.  Delegation administration . . . . . . . . . . . . . . . . . .   7
     3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.1.  One name server within the subzone  . . . . . . . . .   7
       3.1.2.  Two name servers within the subzone . . . . . . . . .   8



Homburg, et al.           Expires 12 July 2025                  [Page 2]

Internet-Draft              incremental-deleg               January 2025


       3.1.3.  Outsourced to an operator . . . . . . . . . . . . . .   8
       3.1.4.  DNSSEC signed name servers within the subzone . . . .   9
   4.  Minimal implementation  . . . . . . . . . . . . . . . . . . .  11
     4.1.  Recursive Resolver behavior . . . . . . . . . . . . . . .  11
     4.2.  _deleg label presence . . . . . . . . . . . . . . . . . .  13
   5.  Optimized implementation  . . . . . . . . . . . . . . . . . .  14
     5.1.  Authoritative name server support . . . . . . . . . . . .  14
     5.2.  Resolver behavior with authoritative name server
           support . . . . . . . . . . . . . . . . . . . . . . . . .  18
   6.  Extra optimized implementation  . . . . . . . . . . . . . . .  19
   7.  Priming queries . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  Comparison with other delegation mechanisms . . . . . . . . .  20
     8.1.  Comparison with legacy delegations  . . . . . . . . . . .  21
     8.2.  Comparison with Name DNS Query Name Minimisation  . . . .  21
     8.3.  Comparison with I-D.dnsop-deleg . . . . . . . . . . . . .  21
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  22
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  DELEG RR type  . . . . . . . . . . . . . . . . . . . . .  22
     11.2.  _deleg Node Name . . . . . . . . . . . . . . . . . . . .  22
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     12.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   This document describes a delegation mechanism for the Domain Name
   System (DNS) [STD13] that addresses several matters that, at the time
   of writing, are suboptimally supported or not supported at all.
   These matters are elaborated upon in sections 1.1, 1.2 and 1.3.  In
   addition, the mechanism described in this document aspires to be
   maximally deployable, which is elaborated upon in Section 1.4.

1.1.  Signaling capabilities of the authoritative name servers

   A new DELEG resource record (RR) type is introduced in this document,
   which is based on and inherits the wire and presentation format from
   SVCB [RFC9460].  All Service Binding Mappings, as well as the
   capability signalling, that are specified in [RFC9461] are also
   applicable to DELEG, with the exception of the limitations on
   AliasMode records in Section 6 of [RFC9460].  Capability signalling
   of DNS over Transport Layer Protocol [RFC7858] (DoT), DNS Queries
   over HTTPS [RFC8484] and DNS over Dedicated QUIC Connections
   [RFC9250], on default or alternative ports, can all be used as
   specified in [RFC9461].  The DELEG RR type inherits its extensibility
   from the SVCB RR type, which is designed to be extensible to support



Homburg, et al.           Expires 12 July 2025                  [Page 3]

Internet-Draft              incremental-deleg               January 2025


   future uses (such as keys for encrypting the TLS ClientHello
   [I-D.ietf-tls-esni].)

1.2.  Outsourcing operation of the delegation

   Delegation information is stored at an authoritative location in the
   zone with this mechanism.  Legacy methods to redirect this
   information to another location, possible under the control of
   another operator, such as (CNAME Section 3.6.2 of [RFC1034]) and
   DNAME [RFC6672] remain functional.  One could even outsource all
   delegation operational practice to another party with an DNAME on the
   _deleg label on the apex of the delegating zone.

   Additional to the legacy methods, a delegation may be outsourced to a
   third parties by having RRs in AliasMode.  Unlike SVCB, DELEG allows
   for more than a single DELEG RR in AliasMode in a DELEG RRset,
   enabling outsourcing a delegation to multiple different operators.

1.3.  DNSSEC protection of the delegation

   With legacy delegations, the NS RRset at the parent side of a
   delegation as well as glue records for the names in the NS RRset are
   not authoritative and not DNSSEC signed.  An adversary that is able
   to spoof a referral response, can alter this information and redirect
   all traffic for the delegation to a rogue name server undetected.
   The adversary can then perceive all queries for the redirected zone
   (Privacy concern) and alter all unsigned parts of responses (such as
   further referrals, which is a Security concern).

   DNSSEC protection of delegation information prevents that, and is the
   only countermeasure that also works against on-path attackers.  At
   the time of writing, the only way to DNSSEC validate and verify
   delegations at all levels in the DNS hierarchy is to revalidate
   delegations [I-D.ietf-dnsop-ns-revalidation], which is done after the
   fact and has other security concerns (Section 7 of
   [I-D.ietf-dnsop-ns-revalidation]).

   Direct delegation information (provided by DELEG RRs in ServiceMode)
   includes the hostnames of the authoritative name servers for the
   delegation as well as IP addresses for those hostnames.  Since the
   information is stored authoritatively in the delegating zone, it will
   be DNSSEC signed if the zone is signed.  When the delegation is
   outsourced, then it's protected when the zones providing the aliasing
   resource records _and_ the zones serving the targets of the aliases
   are all DNSSEC signed.






Homburg, et al.           Expires 12 July 2025                  [Page 4]

Internet-Draft              incremental-deleg               January 2025


1.4.  Maximize ease of deployment

   Delegation information is stored authoritatively within the
   delegation zone.  No semantic changes as to what zones are
   authoritative for what data are needed.  As a consequence, existing
   DNS software, such as authoritative name servers and DNSSEC signing
   software, can remain unmodified.  Unmodified authoritative name
   server software will serve the delegation information when queried
   for.  Unmodified signers will sign the delegation information in the
   delegating zone.  Only the recursive resolver needs modification to
   follow referrals as provided by the delegation information.

   Such a resolver would explicitly query for the delegations
   administered as specified in Section 3.  The number of round trips
   from the recursive resolver to the authoritative name server is
   comparable to what is needed for DNS Query Name Minimisation
   [RFC9156].  Additional implementation in the authoritative name
   server optimizes resolution and reduces the number of simultaneous in
   parallel queries to that what would be needed for legacy delegations.
   None, mixed or full deployment of the mechanism on authoritative name
   servers are all fully functional, allowing for the mechanism to be
   incrementally deployed on the authoritative name servers.

   Implementation in the recursive may be less demanding with respect to
   (among other things) DNSSEC validation because there is no need to
   make additional exceptions as to what is authoritative at the parent
   side of a delegation.

1.5.  Terminology

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

   This document follows terminology as defined in [RFC9499].

   Throughout this document we will also use terminology with the
   meaning as defined below:

   Incremental deleg:
      The delegation mechanism as specified in this document.

   Incremental delegation:
      A delegation as specified in this document

   Legacy delegations:



Homburg, et al.           Expires 12 July 2025                  [Page 5]

Internet-Draft              incremental-deleg               January 2025


      The way delegations are done in the DNS traditionally as defined
      in [STD13].

   Delegating zone:
      The zone in which the delegation is administered.  Sometimes also
      called the "parent zone" of a delegation.

   Subzone:
      The zone that is delegated to from the delegating zone.

   Delegating name:
      The name which realizes the delegation.  In legacy delegations,
      this name is the same as the name of the subzone to which the
      delegation refers.  Delegations described in this document are
      provided with a different name than the zone that is delegated to.

   Delegation point:
      The location in the delegating zone where the RRs are provided
      that make up the delegation.  In legacy delegations, this is the
      parent side of the zone cut and has the same name as the subzone.
      With incremental deleg, this is the location given by the
      delegating name.

   Triggering query:
      The query on which resolution a recursive resolver is working.

   Target zone:
      The zone for which the authoritative servers, that a resolver
      contacts while iterating, are authoritative.

2.  The DELEG resource record type

   The DELEG RR type is a variant of SVCB [RFC9460] for use with
   resolvers to perform iterative resolution (Section 5.3.3 of
   [RFC1034]).  The DELEG type requires registration in the "Resource
   Record (RR) TYPEs" registry under the "Domain Name System (DNS)
   Parameters" registry group (see DELEG RR type (Section 11.1)).  The
   protocol-specific mapping specification for iterative resolutions are
   the same as those for "DNS Servers" [RFC9461].

   Section 2.4.2 of [RFC9460] states that SVCB RRsets SHOULD only have a
   single RR in AliasMode, and that if multiple AliasMode RRs are
   present, clients or recursive resolvers SHOULD pick one at random.
   Different from SVCB (Section 2.4.2 of [RFC9460]), DELEG allows for
   multiple AliasMode RRs to be present in a single DELEG RRset.  Note
   however that the target of a DELEG RR in AliasMode is an SVCB RRset
   for the "dns" service type adhering fully to the Service Binding
   Mapping for DNS Servers as specified in [RFC9461].



Homburg, et al.           Expires 12 July 2025                  [Page 6]

Internet-Draft              incremental-deleg               January 2025


   Section 2.4.1 of [RFC9460] states that within an SVCB RRset, all RRs
   SHOULD have the same mode, and that if an RRset contains a record in
   AliasMode, the recipient MUST ignore any ServiceMode records in the
   set.  Different from SVCB, mixed ServiceMode and AliasMode RRs are
   allowed in a DELEG RRset.

   At the delegation point (for example customer._deleg.example.), the
   host names of the authoritative name servers for the subzone, are
   given in the TargetName RDATA field of DELEG records in ServiceMode.
   Port Prefix Naming Section 3 of [RFC9461] is not used at the
   delegation point, but MUST be used when resolving the aliased to name
   servers with DELEG RRs in AliasMode.

3.  Delegation administration

   An extensible delegation is realized with a DELEG Resource Record set
   (RRset) [RFC9460] below a specially for the purpose reserved label
   with the name _deleg at the apex of the delegating zone.  The _deleg
   label scopes the interpretation of the DELEG records and requires
   registration in the "Underscored and Globally Scoped DNS Node Names"
   registry (see _deleg Node Name (Section 11.2)).  The full scoping of
   delegations includes the labels that are *below* the _deleg label and
   those, together with the name of the delegating domain, make up the
   name of the subzone to which the delegation refers.  For example, if
   the delegating zone is example., then a delegation to subzone
   customer.example. is realized by a DELEG RRset at the name
   customer._deleg.example. in the parent zone.  A fully scoped
   delegating name (such as customer._deleg.example.) is referred to
   further in this document as the "delegation point".

   Note that if the delegation is outsourcing to a single operator
   represented in a single DELEG RR, it is RECOMMENDED to refer to the
   name of the operator's DELEG RRset with a CNAME on the delegation
   point instead of a DELEG RR in AliasMode Section 10.2 of [RFC9460].

3.1.  Examples

3.1.1.  One name server within the subzone

   $ORIGIN example.
   @                  IN  SOA   ns zonemaster ...
   customer1._deleg   IN  DELEG 1 ( ns.customer1
                                    ipv4hint=198.51.100.1,203.0.113.1
                                    ipv6hint=2001:db8:1::1,2001:db8:2::1
                                  )

                Figure 1: One name server within the subzone




Homburg, et al.           Expires 12 July 2025                  [Page 7]

Internet-Draft              incremental-deleg               January 2025


3.1.2.  Two name servers within the subzone

   $ORIGIN example.
   @                  IN  SOA   ns zonemaster ...
   customer2._deleg   IN  DELEG 1 ns1.customer2 ( ipv4hint=198.51.100.1
                                                  ipv6hint=2001:db8:1::1
                                                )
                      IN  DELEG 1 ns2.customer2 ( ipv4hint=203.0.113.1
                                                  ipv6hint=2001:db8:2::1
                                                )

               Figure 2: Two name servers within the subzone

3.1.3.  Outsourced to an operator

   $ORIGIN example.
   @                  IN  SOA   ns zonemaster ...
   customer3._deleg   IN  CNAME _dns.ns.operator1

                      Figure 3: Outsourced with CNAME

   Instead of using CNAME, the outsourcing could also been accomplished
   with a DELEG RRset with a single DELEG RR in AliasMode.  The
   configuration below is operationally equivalent to the CNAME
   configuration above.  It is RECOMMENDED to use a CNAME over a DELEG
   RRset with a single DELEG RR in AliasMode (Section 10.2 of
   [RFC9460]).  Note that a DELEG RRset refers with TargetName to an DNS
   service, which will be looked up using Port Prefix Naming Section 3
   of [RFC9461], but that CNAME refers to the domain name of the target
   DELEG RRset (or CNAME) which may have an _dns prefix.

   $ORIGIN example.
   @                  IN  SOA   ns zonemaster ...
   customer3._deleg   IN  DELEG 0 ns.operator1

              Figure 4: Outsourced with an AliasMode DELEG RR

   The operator DELEG RRset could for example be:













Homburg, et al.           Expires 12 July 2025                  [Page 8]

Internet-Draft              incremental-deleg               January 2025


   $ORIGIN operator1.example.
   @                  IN  SOA   ns zonemaster ...
   _dns.ns            IN  DELEG 1 ns ( alpn=h2,dot,h3,doq
                                       ipv4hint=192.0.2.1
                                       ipv6hint=2001:db8:3::1
                                       dohpath=/q{?dns}
                                     )
                      IN  DELEG 2 ns ( ipv4hint=192.0.2.2
                                       ipv6hint=2001:db8:3::2
                                     )
   ns                 IN  AAAA  2001:db8:3::1
                      IN  AAAA  2001:db8:3::2
                      IN  A     192.0.2.1
                      IN  A     192.0.2.2

                          Figure 5: Operator zone

3.1.4.  DNSSEC signed name servers within the subzone

































Homburg, et al.           Expires 12 July 2025                  [Page 9]

Internet-Draft              incremental-deleg               January 2025


   $ORIGIN
   @                 IN  SOA    ns zonemaster ...
                     IN  RRSIG  SOA ...
                     IN  DNSKEY 257 3 15 ...
                     IN  RRSIG  DNSKEY ...
                     IN  NS     ns.example.
                     IN  NSEC   customer5._deleg SOA RRSIG NSEC DNSKEY
                     IN  RRSIG  NSEC ...

   customer5._deleg  IN  DELEG 1 ns.customer5 alpn=h2,h3 (
                                               ipv4hint=198.51.100.5
                                               ipv6hint=2001:db8:5::1
                                               dohpath=/dns-query{?dns}
                                               )
                     IN  RRSIG  DELEG ...
                     IN  NSEC   customer7._deleg RRSIG NSEC DELEG
                     IN  RRSIG  NSEC ...

   customer7._deleg  IN  CNAME  customer5._deleg
                     IN  RRSIG  CNAME ...
                     IN  NSEC   customer5 CNAME RRSIG NSEC
                     IN  RRSIG  NSEC ...

   customer5         IN  NS     ns.customer5
   ns.customer5      IN  A      198.51.100.5
                     IN  AAAA   2001:db8:5::1
   customer5         IN  DS     17405 15 2 ...
                     IN  RRSIG  DS ...
                     IN  NSEC   customer6 NS DS RRSIG NSEC
                     IN  RRSIG  NSEC ...

   customer6         IN  NS     ns.customer6
   ns.customer6      IN  A      203.0.113.1
                     IN  AAAA   2001:db8:6::1
   customer6         IN  DS     ...
                     IN  RRSIG  DS ...
                     IN  NSEC   customer7 NS DS RRSIG NSEC
                     IN  RRSIG  NSEC ...

   customer7         IN  NS     ns.customer5
                     IN  DS     ...
                     IN  RRSIG  DS ...
                     IN  NSEC   example. NS DS RRSIG NSEC
                     IN  RRSIG  NSEC ...

               Figure 6: DNSSEC signed incremental deleg zone





Homburg, et al.           Expires 12 July 2025                 [Page 10]

Internet-Draft              incremental-deleg               January 2025


   customer5.example. is delegated to in an extensible way and
   customer6.example. is delegated only in a legacy way.
   customer7.example.'s delegation is outsourced to customer5's
   delegation.

   The delegation signals that the authoritative name server supports
   DoH. customer5.example., customer6.example. and example. are all
   DNSSEC signed.  The DNSSEC authentication chain links from example.
   to customer5.example. in the for DNSSEC conventional way with the
   signed customer5.example.  DS RRset in the example. zone.  Also,
   customer6.example. is linked to from example. with the signed
   customer6.example.  DS RRset in the example. zone.

   Note that both customer5.example. and customer6.example. have legacy
   delegations in the zone as well.  It is important to have those
   legacy delegations to maintain support for legacy resolvers, that do
   not support incremental deleg.  DNSSEC signers SHOULD construct the
   NS RRset and glue for the legacy delegation from the DELEG RRset.

4.  Minimal implementation

   Support in recursive resolvers suffices for the mechanism to be fully
   functional.  Section 4.1 specifies the basic algorithm for resolving
   incremental delegations.  In Section 4.2, an optimization is
   presented that will reduce the number of (parallel) queries
   especially for when authoritative name server support is still
   lacking and there are still many zones that do not contain
   incremental delegations.

4.1.  Recursive Resolver behavior

   If the triggering query name is the same as the name of the target
   zone apex, then no further delegation will occur, and resolution will
   complete.  No special behavior or processing is needed.

   Otherwise, the triggering query is below the target zone apex and a
   delegation may exist in the target zone.  In this case two parallel
   queries MUST be sent.  One for the triggering query in the way that
   is conventional with legacy delegations (which could be just the
   triggering query or a minimised query [RFC9156]), and one
   _incremental deleg query_ with query type DELEG.

   The incremental deleg query name is constructed by concatenating the
   first label below the part that the triggering query name has in
   common with the target zone, a _deleg label and the name of the
   target zone.  For example if the triggering query is
   www.customer.example. and the target zone example., then the
   incremental deleg query name is customer._deleg.example.  For another



Homburg, et al.           Expires 12 July 2025                 [Page 11]

Internet-Draft              incremental-deleg               January 2025


   example, if the triggering query is www.faculty.university.example.
   and the target zone example. then the incremental deleg name is
   university._deleg.example.

   Normal DNAME, CNAME and DELEG in AliasMode processing should happen
   as before, though note that when following a DELEG RR in AliasMode
   the target RR type is SVCB (see Section 2).  The eventual incremental
   deleg query response, after following all redirections caused by
   DNAME, CNAME and AliasMode DELEG RRs, has three possible outcomes:

   1.  A DELEG RRset in ServiceMode is returned in the response's answer
       section containing the delegation for the subzone.

       The DELEG RRs in the RRset MUST be used to follow the referral.
       The TargetName data field in the DELEG RRs in the RRset MUST be
       used as the names for the name servers to contact for the
       subzone, and the ipv4hint and ipv6hint parameters MUST be used as
       the IP addresses for the TargetName in the same DELEG RR.

       The NS RRset and glue, in the response of the legacy query that
       was sent in parallel to the incremental deleg query, MUST NOT be
       used, but the signed DS record (or NSEC(3) records indicating
       that there was no DS) MUST be used in linking the DNSSEC
       authentication chain as which would conventionally be done with
       DNSSEC as well.

   2.  The incremental deleg query name does not exist (NXDOMAIN).

       There is no incremental delegation for the subzone, and the
       referral response for the legacy delegation MUST be processed as
       would be done with legacy DNS and DNSSEC processing.

   3.  The incremental deleg query name does exist, but resulted in a
       NOERROR no answer response (also known as a NODATA response).

       If the legacy query, did result in a referral for the same number
       of labels as the subdomain that the incremental deleg query was
       for, then there was no incremental delegation for the subzone,
       and the referral response for the legacy delegation MUST be
       processed as would be done with legacy DNS and DNSSEC processing.

       Otherwise, the subzone may be more than one label below the
       delegating zone.

       If the response to the legacy query resulted in a referral, then
       a new incremental deleg query MUST be spawned, matching the zone
       cut of the legacy referral response.  For example if the
       triggering query is www.university.ac.example. and the target



Homburg, et al.           Expires 12 July 2025                 [Page 12]

Internet-Draft              incremental-deleg               January 2025


       zone example., and the legacy response contained an NS RRset for
       university.ac.example., then the incremental deleg query name is
       university.ac._deleg.example.  The response to the new
       incremental deleg query MUST be processed as described above, as
       if it was the initial incremental deleg query.

       If the legacy query was sent minimised and needs a followup
       query, then parallel to that followup query a new incremental
       deleg query will be sent, adding a single label to the previous
       incremental deleg query name.  For example if the triggering
       query is www.university.ac.example. and the target zone is
       example. and the minimised legacy query name is ac.example.
       (which also resulted in a NOERROR no answer response), then the
       incremental deleg query to be sent along in parallel with the
       followup legacy query will become university.ac.example.
       Processing of the responses of those two new queries will be done
       as described above.

4.2.  _deleg label presence

   Absence of the _deleg label in a zone is a clear signal that the zone
   does not contain any incremental deleg delegations.  Recursive
   resolvers SHOULD NOT send any additional incremental deleg queries
   for zones for which it is known that it does not contain the _deleg
   label at the apex.  The state regarding the presence of the _deleg
   label within a resolver can be "unknown", "known not to be present",
   or "known to be present".

   The state regarding the presence of the _deleg label can be deduced
   from the response of the incremental deleg query, if the target zone
   is signed with DNSSEC.  If the target zone is unsigned, the procedure
   as described in the remainder of this section SHOULD be followed.

   When the presence of a _deleg label is "unknown", a _deleg presence
   test query SHOULD be sent in parallel to the next query for the
   unsigned target zone (though not when the target name server is known
   to support incremental deleg, which will be discussed in
   Section 5.1).  The query name for the test query is the _deleg label
   prepended to the apex of zone for which to test presence, with query
   type A.

   The testing query can have three possible outcomes:

   1.  The _deleg label does not exist within the zone, and an NXDOMAIN
       response is returned.






Homburg, et al.           Expires 12 July 2025                 [Page 13]

Internet-Draft              incremental-deleg               January 2025


       The non-existence of the _deleg label MUST be cached for the
       duration indicated by the "minimum" RDATA field of the SOA
       resource record in the authority section, adjusted to the
       boundaries for TTL values that the resolver has (Section 4 of
       [RFC8767]).  For the period the non-existence of the _deleg label
       is cached, the label is "known not to be present" and the
       resolver SHOULD NOT send any (additional) incremental deleg
       queries.

   2.  The _deleg label does exist within the zone but contains no data.
       A NOERROR response is returned with no RRs in the answer section.

       The existence of the _deleg name MUST be cached for the duration
       indicated by the "minimum" RDATA field of the SOA resource record
       in the authority section, adjusted to the resolver's TTL
       boundaries.  For the period the existence of the empty non-
       terminal at the _deleg label is cached, the label is "known to be
       present" and the resolver MUST send additional incremental deleg
       queries as described in TODO.

   3.  The _deleg label does exist within the zone and contains data.  A
       NOERROR response is return with an A RRset in the answer section.

       The resolver MUST record that the _deleg label is known to be
       present for a duration indicated by A RRset's TTL value, adjusted
       to the resolver's TTL boundaries, for example by caching the
       RRset.  For the period any RRset at the _deleg label is cached,
       the label is "known to be present" and the resolver MUST send
       additional incremental deleg queries as described in TODO.

5.  Optimized implementation

   Support for authoritative name servers enables optimized query
   behavior by resolvers with reduced (simultaneous) queries.
   Section 5.1 specifies how incremental deleg supporting authoritative
   name servers return referral responses for delegations.  In
   Section 5.2 we specify how resolvers can benefit from those
   authoritative servers.

5.1.  Authoritative name server support

   Incremental delegations supporting authoritative name servers include
   the incremental delegation information (or the NSEC(3) records
   showing the non-existence) in the authority section of referral
   responses to legacy DNS queries.  For example, querying the zone from
   Figure 6 for www.customer5.example.  A, will return the following
   referral response:




Homburg, et al.           Expires 12 July 2025                 [Page 14]

Internet-Draft              incremental-deleg               January 2025


   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 54349
   ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 2
   ;; QUESTION SECTION:
   ;; www.customer5.example.       IN      A

   ;; ANSWER SECTION:

   ;; AUTHORITY SECTION:
   customer5.example.      3600    IN      NS      ns.customer5.example.
   customer5.example.      3600    IN      DS      ...
   customer5.example.      3600    IN      RRSIG   DS ...
   customer5._deleg.example.       3600    IN      DELEG 1 (
                   ns.customer5.example. alpn=h2,h3
                   ipv4hint=198.51.100.5 ipv6hint=2001:db8:5::1
                   dohpath=/dns-query{?dns}
                   )
   customer5._deleg.example.       3600    IN      RRSIG   DELEG ...

   ;; ADDITIONAL SECTION:
   ns.customer5.example.   3600    IN      A       198.51.100.5
   ns.customer5.example.   3600    IN      AAAA    2001:db8:5::1

   ;; Query time: 0 msec
   ;; EDNS: version 0; flags: do ; udp: 1232
   ;; SERVER: 192.0.2.53
   ;; WHEN: Mon Jul  1 20:36:25 2024
   ;; MSG SIZE  rcvd: 456

              Figure 7: An incremental deleg referral response

   The referral response in Figure 7 includes the signed DELEG RRset in
   the authority section.

   As another example, querying the zone from Figure 6 for
   www.customer6.example.  A, will return the following referral
   response:















Homburg, et al.           Expires 12 July 2025                 [Page 15]

Internet-Draft              incremental-deleg               January 2025


   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36574
   ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 2
   ;; QUESTION SECTION:
   ;; www.customer6.example.       IN      A

   ;; ANSWER SECTION:

   ;; AUTHORITY SECTION:
   customer6.example.      3600    IN      NS      ns.customer6.example.
   customer6.example.      3600    IN      DS      ...
   customer6.example.      3600    IN      RRSIG   DS ...
   customer5._deleg.example.       1234    IN      NSEC    (
                   customer7._deleg.example.  RRSIG NSEC DELEG )
   customer5._deleg.example.       1234    IN      RRSIG   NSEC ...
   example.        1234    IN      NSEC    (
                   customer5._deleg.example.  NS SOA RRSIG NSEC DNSKEY )
   example.        1234    IN      RRSIG   NSEC ...

   ;; ADDITIONAL SECTION:
   ns.customer6.example.   3600    IN      A       203.0.113.1
   ns.customer6.example.   3600    IN      AAAA    2001:db8:6::1

   ;; Query time: 0 msec
   ;; EDNS: version 0; flags: do ; udp: 1232
   ;; SERVER: 192.0.2.53
   ;; WHEN: Tue Jul  2 10:23:53 2024
   ;; MSG SIZE  rcvd: 744

           Figure 8: Referral response without incremental deleg

   Next to the legacy delegation, the incremental deleg supporting
   authoritative returns the NSEC(3) RRs needed to show that there was
   no incremental delegation in the referral response in Figure 8.

   Querying the zone from Figure 6 for www.customer7.example.  A, will
   return the following referral response:















Homburg, et al.           Expires 12 July 2025                 [Page 16]

Internet-Draft              incremental-deleg               January 2025


   ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 9456
   ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 2
   ;; QUESTION SECTION:
   ;; www.customer7.example.       IN      A

   ;; ANSWER SECTION:

   ;; AUTHORITY SECTION:
   customer7.example.      3600    IN      NS      ns.customer5.example.
   customer7.example.      3600    IN      DS      ...
   customer7.example.      3600    IN      RRSIG   DS ...
   customer7._deleg.example.       3600    IN      CNAME   (
                   customer5._deleg.example. )
   customer7._deleg.example.       3600    IN      RRSIG   CNAME ...
   customer5._deleg.example.       3600    IN      DELEG   1 (
                   ns.customer5.example. alpn=h2,h3
                   ipv4hint=198.51.100.5 ipv6hint=2001:db8:5::1 )
   customer5._deleg.example.       3600    IN      RRSIG   DELEG ...

   ;; ADDITIONAL SECTION:
   ns.customer5.example.   3600    IN      A       198.51.100.5
   ns.customer5.example.   3600    IN      AAAA    2001:db8:5::1

   ;; Query time: 0 msec
   ;; EDNS: version 0; flags: do ; udp: 1232
   ;; SERVER: 192.0.2.53
   ;; WHEN: Tue Jul  2 10:55:07 2024
   ;; MSG SIZE  rcvd: 593

                    Figure 9: Aliasing referral response

   The incremental delegation of customer7.example. is aliased to the
   one that is also used by customer5.example.  Since both delegations
   are in the same zone, the authoritative name server for example.
   returns both the CNAME realising the alias, as well as the DELEG
   RRset which is the target of the alias in Figure 9.  In other cases
   an returned CNAME or DELEG RR in AliasMode may need further chasing
   by the resolver.

   With unsigned zones, only if an incremental deleg delegation exists,
   the DELEG RRset (or CNAME) will be present in the authority section
   of referral responses.  If the incremental deleg does not exist, then
   it is simply absent from the authority section and the referral
   response is indistinguishable from an non supportive authoritative.







Homburg, et al.           Expires 12 July 2025                 [Page 17]

Internet-Draft              incremental-deleg               January 2025


5.2.  Resolver behavior with authoritative name server support

   Incremental deleg supporting authoritative name servers will include
   the incremental delegation information (or the NSEC(3) records
   showing the non-existence) in the authority section of referral
   responses.  If it is known that an authoritative name server supports
   incremental deleg, then no direct queries for the incremental
   delegation need to be send in parallel to the legacy delegation
   query.  A resolver SHOULD register that an authoritative name server
   supports incremental deleg when the authority section, of the
   returned referral responses from that authoritative name server,
   contains incremental delegegation information.

   When the authority section of a referral response contains a DELEG
   RRset or a CNAME on the incremental delegation name, or valid NSEC(3)
   RRs showing the non-existence of such DELEG or CNAME RRset, then the
   resolver SHOULD register that the contacted authoritative name server
   supports incremental deleg for the duration indicated by the TTL for
   that DELEG, CNAME or NSEC(3) RRset, adjusted to the resolver's TTL
   boundaries, but only if it is longer than any already registered
   duration.  Subsequent queries SHOULD NOT include incremental deleg
   queries, as described in Section 4.1, to be send in parallel for the
   duration support for incremental deleg is registered for the
   authoritative name server.

   For example, in Figure 7, the DELEG RRset at the incremental
   delegation point has TTL 3600.  The resolver should register that the
   contacted authoritative name server supports incremental deleg for
   (at least) 3600 seconds (one hour).  All subsequent queries to that
   authoritative name server SHOULD NOT include incremental deleg
   queries to be send in parallel.

   If the authority section contains more than one RRset making up the
   incremental delegation, then the RRset with the longest TTL MUST be
   taken to determine the duration for which incremental deleg support
   is registered.

   For example, in Figure 9, both a CNAME and a DELEG RRset for the
   incremental delegation are included in the authority section.  The
   longest TTL must be taken for incremental support registration,
   though because the TTL of both RRsets is 3600, it does not matter in
   this case.

   With DNSSEC signed zones, support is apparent with all referral
   responses, with unsigned zones only from referral responses for which
   a incremental delegation exists.





Homburg, et al.           Expires 12 July 2025                 [Page 18]

Internet-Draft              incremental-deleg               January 2025


   If the resolver knows that the authoritative name server supports
   incremental deleg, _and_ a DNSSEC signed zone is being served, then
   all referrals MUST contain either an incremental delegation, or
   NSEC(3) records showing that the delegation does not exist.  If a
   referral is returned that does not contain an incremental delegation
   nor an indication that it does not exist, then the resolver MUST send
   an additional incremental deleg query to find the incremental
   delegation (or denial of its existence).

6.  Extra optimized implementation

   A DELEG RRset on an incremental delegation point, with a DELEG RR in
   AliasMode, aliasing to the root zone, MUST be interpreted to mean
   that the legacy delegation information MUST be used to follow the
   referral.  All service parameters for such AliasMode (aliasing to the
   root) DELEG RRs on the incremental delegation point, MUST be ignored.

   For example, such a DELEG RRset registered on the wildcard below the
   _deleg label on the apex of a zone, can signal that legacy DNS
   referrals MUST be used for both signed and _unsigned_ zones:

   $ORIGIN example.
   @                  IN  SOA   ns zonemaster ...
   *._deleg    86400  IN  DELEG 0 .
   customer1._deleg   IN  DELEG 1 ( ns.customer1
                                    ipv4hint=198.51.100.1,203.0.113.1
                                    ipv6hint=2001:db8:1::1,2001:db8:2::1
                                  )
   customer3._deleg   IN  CNAME _dns.ns.operator1

        Figure 10: Wildcard incremental deleg to control duration of
                              detected support

   Resolvers SHOULD register that an authoritative name server supports
   incremental deleg, if such a DELEG RRset is returned in the authority
   section of referral responses, for the duration of the TTL if the
   DELEG RRset, adjusted to the resolver's TTL boundaries, but only if
   it is longer than any already registered duration.  Note that this
   will also be included in referral responses for unsigned zones, which
   would otherwise not have signalling of incremental deleg support by
   the authoritative name server.  Also, signed zones need fewer RRs to
   indicate that no incremental delegation exists.  The wildcard
   expansion already shows the closest encloser (i.e. _deleg.<apex>), so
   only one additional NSEC(3) is needed to show non-existence of the
   queried for name below the closest encloser.

   This method of signalling that the legacy delegation MUST be used, is
   RECOMMENDED.



Homburg, et al.           Expires 12 July 2025                 [Page 19]

Internet-Draft              incremental-deleg               January 2025


7.  Priming queries

   Some zones, such as the root zone, are targeted directly from hints
   files.  Information about which authoritative name servers and with
   capabilities, MAY be provided in a DELEG RRset directly at the _deleg
   label under the apex of the zone.  Priming queries from a incremental
   deleg supporting resolver, MUST send an _deleg.<apex> DELEG query in
   parallel to the legacy <apex> NS query and process the content as if
   it was found through an incremental referral response.

8.  Comparison with other delegation mechanisms

   Table Table 1 provides an overview of when extra queries, in parallel
   to the legacy query, are sent.

   +=+====+=========+=========++=====================+================+
   | |apex| support |  _deleg || <sub>._deleg.<apex> | _deleg.<apex>  |
   | |    |         |         ||        DELEG        |       A        |
   +=+====+=========+=========++=====================+================+
   |1|Yes |    *    |    *    ||                     |                |
   +-+----+---------+---------++---------------------+----------------+
   |2| No |    *    |    No   ||                     |                |
   +-+----+---------+---------++---------------------+----------------+
   |3| No |   Yes   |    *    ||                     |                |
   +-+----+---------+---------++---------------------+----------------+
   |4| No | Unknown |   Yes   ||          X          |                |
   +-+----+---------+---------++---------------------+----------------+
   |5| No | Unknown | Unknown ||          X          |    only for    |
   | |    |         |         ||                     | unsigned zones |
   +-+----+---------+---------++---------------------+----------------+

       Table 1: Additional queries in parallel to the legacy query

   The three headers on the left side of the table mean the following:

   apex:
      Whether the query is for the apex of the target zone.  "Yes" means
      an apex query, "No" means a query below the apex which may be
      delegated

   support:
      Whether or not the target authoritative server supports
      incremental deleg.  "Yes" means it supports it and "Unknown" means
      support is not detected. "*" means it does not matter

   _deleg:
      Whether or not the _deleg label is present in the target zone (and
      thus incremental delegations)



Homburg, et al.           Expires 12 July 2025                 [Page 20]

Internet-Draft              incremental-deleg               January 2025


   On the right side of the table are the extra queries, to be sent in
   parallel with the legacy query.  The _deleg presence test query (most
   right column) only needs to be sent to unsigned target zones, because
   its non-existence will be show in the NSEC(3) records showing the
   non-existence of the incremental delegation (second from right
   column).

   If the query name is the same as the apex of the target zone, no
   extra queries need to be sent (Row 1).  If the _deleg label is known
   not to exist in the target zone (Row 2) or if the target name server
   is known to support incremental deleg (Row 3), no extra queries need
   to be sent.  Only if it is unknown that the target name server
   supports incremental deleg, and the _deleg label is known to exist in
   the target zone (Row 4) or it its not known whether or not the _deleg
   label exists (Row 5), and extra incremental deleg query is sent in
   parallel to the legacy query.  If the target zone is unsigned,
   presence of the _deleg label needs to be tested explicitly (Row 5).

8.1.  Comparison with legacy delegations

8.2.  Comparison with Name DNS Query Name Minimisation

8.3.  Comparison with [I-D.dnsop-deleg]

    +=================================+==============================+
    | [I-D.dnsop-deleg]               | [this document]              |
    +=================================+==============================+
    | Requires implementation in both | Only resolver implementation |
    | authoritative name server as    | required.  But optimized     |
    | well as in the resolver         | with updated authoritative   |
    |                                 | software.                    |
    +---------------------------------+------------------------------+
    | DNSKEY flag needed to signal    | No DNSKEY flag needed.       |
    | DELEG support with all          | Separation of concerns.      |
    | authoritative name servers that |                              |
    | serve the parent (delegating)   |                              |
    | domain.  Special requirements   |                              |
    | for the child domain.           |                              |
    +---------------------------------+------------------------------+
    | Authoritative name servers need | Authoritative name servers   |
    | to be updated all at once       | may be updated gradually for |
    |                                 | optimization                 |
    +---------------------------------+------------------------------+
    | New semantics about what is     | Works with current DNS and   |
    | authoritative (BOGUS with       | DNSSEC semantics.  Easier to |
    | current DNSSEC validators)      | implement.                   |
    +---------------------------------+------------------------------+
    | No extra queries                | An extra query, in parallel  |



Homburg, et al.           Expires 12 July 2025                 [Page 21]

Internet-Draft              incremental-deleg               January 2025


    |                                 | to the legacy query, _per    |
    |                                 | authoritative_ server when   |
    |                                 | incremental deleg support is |
    |                                 | not yet detected, and _per   |
    |                                 | unsigned zone_ to determine  |
    |                                 | presence of the _deleg label |
    +---------------------------------+------------------------------+

      Table 2: Comparison of [I-D.dnsop-deleg] with [this document]

9.  Implementation Status

   *Note to the RFC Editor*: please remove this entire section before
   publication.

   Jesse van Zutphen has built a proof of concept implementation
   supporting delegations as specified in this document for the Unbound
   recursive resolver as part of his master thesis for the Security and
   Network Engineering master program of the University of Amsterdam.
   [JZUTPHEN] The source code of his implementation is available on
   github [DELEG4UNBOUND]

10.  Security Considerations

   TODO Security

11.  IANA Considerations

11.1.  DELEG RR type

   IANA is requested to update the "Resource Record (RR) TYPEs" registry
   under the "Domain Name System (DNS) Parameters" registry group as
   follows:

             +=======+=======+============+=================+
             | TYPE  | Value | Meaning    | Reference       |
             +=======+=======+============+=================+
             | DELEG | TBD   | Delegation | [this document] |
             +-------+-------+------------+-----------------+

                                 Table 3

11.2.  _deleg Node Name

   Per [RFC8552], IANA is requested to add the following entry to the
   DNS "Underscored and Globally Scoped DNS Node Names" registry:





Homburg, et al.           Expires 12 July 2025                 [Page 22]

Internet-Draft              incremental-deleg               January 2025


                +=========+============+=================+
                | RR Type | _NODE NAME | Reference       |
                +=========+============+=================+
                | DELEG   | _deleg     | [this document] |
                +---------+------------+-----------------+

                  Table 4: Entry in the Underscored and
                      Globally Scoped DNS Node Names
                                 registry

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <https://www.rfc-editor.org/rfc/rfc6672>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

   [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
              Name Minimisation to Improve Privacy", RFC 9156,
              DOI 10.17487/RFC9156, November 2021,
              <https://www.rfc-editor.org/rfc/rfc9156>.






Homburg, et al.           Expires 12 July 2025                 [Page 23]

Internet-Draft              incremental-deleg               January 2025


   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

   [STD13]    Internet Standard 13,
              <https://www.rfc-editor.org/info/std13>.
              At the time of writing, this STD comprises the following:

              Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

              Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

12.2.  Informative References

   [DELEG4UNBOUND]
              van Zutphen, J., "A proof of concept implementation of
              incremental deleg", n.d.,
              <https://github.com/jessevz/unbound/>.

   [I-D.dnsop-deleg]
              April, T., Špaček, P., Weber, R., and Lawrence,
              "Extensible Delegation for DNS", Work in Progress,
              Internet-Draft, draft-dnsop-deleg-00, 23 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-dnsop-deleg-
              00>.

   [I-D.ietf-dnsop-ns-revalidation]
              Huque, S., Vixie, P. A., and W. Toorop, "Delegation
              Revalidation by DNS Resolvers", Work in Progress,
              Internet-Draft, draft-ietf-dnsop-ns-revalidation-08, 8
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dnsop-ns-revalidation-08>.





Homburg, et al.           Expires 12 July 2025                 [Page 24]

Internet-Draft              incremental-deleg               January 2025


   [I-D.ietf-tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-22, 15 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-22>.

   [I-D.tapril-ns2]
              April, T., "Parameterized Nameserver Delegation with NS2
              and NS2T", Work in Progress, Internet-Draft, draft-tapril-
              ns2-01, 13 July 2020,
              <https://datatracker.ietf.org/doc/html/draft-tapril-
              ns2-01>.

   [JZUTPHEN] van Zutphen, J., "Extensible delegations in DNS Recursive
              resolvers", n.d.,
              <https://nlnetlabs.nl/downloads/publications/extensible-
              deleg-in-resolvers_2024-07-08.pdf>.

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8552>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

Acknowledgments

   The idea to utilize SVCB based RRs to signal capabilities was first
   proposed by Tim April in [I-D.tapril-ns2].

   The idea to utilize SVCB for extensible delegations (and also the
   idea described in this document) emerged from the DNS Hackathon at
   the IETF 118.  The following participants contributed to this
   brainstorm session: Vandan Adhvaryu, Roy Arends, David Blacka, Manu
   Bretelle, Vladimír Čunát, Klaus Darilion, Peter van Dijk, Christian
   Elmerot, Bob Halley, Shumon Huque, Shane Kerr, David C Lawrence,
   Edward Lewis, George Michaelson, Erik Nygren, Libor Peltan, Ben
   Schwartz, Petr Špaček, Jan Včelák and Ralf Weber

Authors' Addresses

   Philip Homburg
   NLnet Labs
   Email: philip@nlnetlabs.nl




Homburg, et al.           Expires 12 July 2025                 [Page 25]

Internet-Draft              incremental-deleg               January 2025


   Tim Wicinski
   Cox Communications
   Email: tjw.ietf@gmail.com


   Jesse van Zutphen
   University of Amsterdam
   Email: Jesse.vanZutphen@os3.nl


   Willem Toorop
   NLnet Labs
   Email: willem@nlnetlabs.nl






































Homburg, et al.           Expires 12 July 2025                 [Page 26]