Incrementally Deployable Extensible Delegation for DNS

1.1. Signaling capabilities of the authoritative name servers

A new IDELEG 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 IDELEG, 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 IDELEG RR type inherits its extensibility from the SVCB RR type, which is designed to be extensible to support future uses (such as keys for encrypting the TLS ClientHello [I-D.ietf-tls-esni].)¶

1.2. Note to the RFC Editor: please remove this subsection before publication.

The name IDELEG is chosen to avoid confusion with [I-D.wesplaap-deleg].¶

1.3. 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, IDELEG allows for more than a single IDELEG RR in AliasMode in a IDELEG RRset, enabling outsourcing a delegation to multiple different operators.¶

1.4. 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 IDELEG 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.¶

1.5. 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.6. 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 [BCP219].¶

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:

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.¶

3.1. Examples

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

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

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

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

$ORIGIN operator1.example.
@                 IN  SOA    ns zonemaster ...
_dns.ns           IN  IDELEG 1 ns ( alpn=h2,dot,h3,doq
                                    ipv4hint=192.0.2.1
                                    ipv6hint=2001:db8:3::1
                                    dohpath=/q{?dns}
                                  )
                  IN  IDELEG 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

$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  IDELEG 1 ns.customer5 alpn=h2,h3 (
                                            ipv4hint=198.51.100.5
                                            ipv6hint=2001:db8:5::1
                                            dohpath=/dns-query{?dns}
                                            )
                  IN  RRSIG  IDELEG ...
                  IN  NSEC   customer7._deleg RRSIG NSEC IDELEG
                  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 ...

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 IDELEG.¶

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 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 IDELEG in AliasMode processing should happen as before, though note that when following a IDELEG 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 IDELEG RRs, has three possible outcomes:¶

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

   The IDELEG RRs in the RRset MUST be used to follow the referral. The TargetName data field in the IDELEG 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 IDELEG 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 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 NS.¶

The testing query can have three possible outcomes:¶

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

   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 Section 4.1.¶

3. The _deleg label does exist within the zone, but is an delegation. A NOERROR legacy referral response is returned with an NS RRset in the authority section.¶

   The resolver MUST record that the zone does not have valid incremental delegations deployed for the duration indicated by the NS RRset's TTL value, adjusted to the resolver's TTL boundaries. For the period indicated by the NS RRset's TTL value, the zone is considered to not to have valid incremental delegations, and MUST NOT send any (additional) incremental deleg queries.¶

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:¶

;; ->>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      IDELEG 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   IDELEG ...

;; 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 Feb 24 20:36:25 2025
;; MSG SIZE  rcvd: 456

The referral response in Figure 7 includes the signed IDELEG 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:¶

;; ->>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 IDELEG )
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 Feb 25 10:23:53 2025
;; MSG SIZE  rcvd: 744

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:¶

;; ->>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      IDELEG   1 (
                ns.customer5.example. alpn=h2,h3
                ipv4hint=198.51.100.5 ipv6hint=2001:db8:5::1 )
customer5._deleg.example.       3600    IN      RRSIG   IDELEG ...

;; 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 Feb 25 10:55:07 2025
;; MSG SIZE  rcvd: 593

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 IDELEG RRset which is the target of the alias in Figure 9. In other cases an returned CNAME or IDELEG RR in AliasMode may need further chasing by the resolver.¶

With unsigned zones, only if an incremental deleg delegation exists, the IDELEG 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.¶

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. For an unsigned zone, an incremental deleg supporting authoritative cannot return that an incremental delegation is absent (because of lack of an authenticated denial of existence), however with support from the served zone (the zone has the Resource Record provisioned *._deleg IN IDELEG 0 .), the authoritative name server can signal support also for unsigned zones (see Extra optimized implementation (Section 6)).¶

If it is known that an authoritative name server supports incremental deleg, then no direct queries for the incremental delegation need to be sent 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 delegation information.¶

When the authority section of a referral response contains a IDELEG RRset or a CNAME on the incremental delegation name, or valid NSEC(3) RRs showing the non-existence of such IDELEG 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 IDELEG, 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 IDELEG 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 IDELEG 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, support is apparent only from referral responses for which an incremental delegation exists, unless the zone has the Resource Record *._deleg IN IDELEG 0 . provisioned (see Extra optimized implementation (Section 6)).¶

If the resolver knows that the authoritative name server supports incremental deleg, and a DNSSEC signed zone is being served, then all referrals SHOULD 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 MAY register that authoritative server does not support incremental deleg and MUST send an additional incremental deleg query to find the incremental delegation (or denial of its existence).¶

9.1. Comparison with legacy delegations

9.2. Comparison with Name DNS Query Name Minimisation

There are no extra queries needed in most cases if the authoritative name server has incremental deleg support. The exception is when the parent zone is not signed and has no incremental deleg records. In that case, one extra query is needed when the parent zone is first contacted (and every TTL)¶

9.3. Comparison with [I-D.wesplaap-deleg]

12.1. IDELEG RR type

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

12.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:¶