DNSOP R. Arends Internet-Draft ICANN Updates: 1034, 4035, 6672, 6840, 6895, 9824 (if P. van Dijk approved) PowerDNS Intended status: Standards Track P. Špaček Expires: 21 March 2027 ISC 17 September 2026 DNS Protocol Modifications for Delegation Extensions draft-ietf-dnsop-delext-11 Abstract The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document specifies modifications to the DNS protocol to permit a range of Resource Record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. This document updates RFCs 1034, 4035, 6672, 6840, 6895 and 9824. 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 21 March 2027. Copyright Notice Copyright (c) 2026 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. Arends, et al. Expires 21 March 2027 [Page 1] Internet-Draft DELEXT September 2026 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2.1. Relationship with the Extensible Delegation for DNS . . . 4 2.2. Relationship with NS and DS Records . . . . . . . . . . . 4 3. Delegation Types . . . . . . . . . . . . . . . . . . . . . . 4 3.1. NS-Omitting Delegation Types . . . . . . . . . . . . . . 5 3.2. NS-Preserving Delegation Types . . . . . . . . . . . . . 5 3.3. On-Demand Delegation Types . . . . . . . . . . . . . . . 5 3.4. Private Delegation Types . . . . . . . . . . . . . . . . 5 3.5. Updates to Allocation Policy . . . . . . . . . . . . . . 5 3.5.1. Criteria for Delegation Type Allocation . . . . . . . 5 4. Name Server Requirements . . . . . . . . . . . . . . . . . . 6 4.1. Including Delegation Types in a Referral Response . . . . 6 4.1.1. Compact Denial of Existence . . . . . . . . . . . . . 7 4.2. Explicit Queries for Delegation Types . . . . . . . . . . 7 4.3. Queries for type ANY . . . . . . . . . . . . . . . . . . 8 4.4. Delegation Types at a Wildcard Domain Name . . . . . . . 8 5. Resolver Requirements . . . . . . . . . . . . . . . . . . . . 8 5.1. The EDNS(0) DE Flag . . . . . . . . . . . . . . . . . . . 8 5.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Algorithm for "Finding the Best Servers to Ask" . . . . . 9 6. DNSSEC Requirements . . . . . . . . . . . . . . . . . . . . . 11 6.1. The DNSKEY-ADT Flag . . . . . . . . . . . . . . . . . . . 12 6.2. Validating a Referral . . . . . . . . . . . . . . . . . . 12 6.3. Clarifications on Nonexistence Proofs . . . . . . . . . . 13 6.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . 13 7. Operational Considerations . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 14 8.2.1. Stripping of Delegation Types from Referrals . . . . 14 8.2.2. Stripping of the DE Flag from Queries . . . . . . . . 15 8.2.3. Interaction Between Flag-Stripping Attacks . . . . . 15 8.3. Injection of Delegation Types . . . . . . . . . . . . . . 16 8.4. Denial-of-Service via a Negative Response for non-Delegation-Extension-aware Resolvers . . . . . . . . 16 8.5. Partial Deployment and Transition Risks . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. The EDNS(0) DE Flag . . . . . . . . . . . . . . . . . . . 18 9.2. The DNSKEY-ADT Flag . . . . . . . . . . . . . . . . . . . 18 Arends, et al. Expires 21 March 2027 [Page 2] Internet-Draft DELEXT September 2026 9.3. Changes to the DNS Parameters RR Types Registry . . . . . 18 9.4. Additional Expert Review Criteria . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Existing DNS protocol semantics permit only the Delegation Signer (DS) RR type to exist as authoritative data at a delegation point [RFC4034]. New delegation mechanisms such as [I-D.ietf-deleg] require additional RR types with the same semantics. Rather than defining special protocol handling for each such RR type independently, this document defines a generic class of Delegation Types, reserves a range of RR type codes for Delegation Types, divides that range into segments with distinct protocol semantics, and specifies the protocol behavior common to all such types. Support for Delegation Types is negotiated using the EDNS(0) [RFC6891] Delegation Extensions (DE) flag, specified in Section 5.1. This ensures that implementations that do not support this specification continue to interoperate using existing DNS delegation semantics. To protect the negotiation mechanism against downgrade attacks, a DNSKEY flag is introduced in Section 6.1. 2. Conventions and Definitions This document makes use of the terms defined in [RFC9499]. In addition, this document defines the following terms: * Delegation Types: Designates the set of RR types allocated from the ranges reserved in Section 3 of this document. NS and DS types are not Delegation Types. * Delegation-Extension-aware name server, resolver, forwarder, or stub resolver: A client or server that implements this specification. 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. Arends, et al. Expires 21 March 2027 [Page 3] Internet-Draft DELEXT September 2026 2.1. Relationship with the Extensible Delegation for DNS [I-D.ietf-deleg] specifies a new type (DELEG) that is authoritative at a delegation point, allocated from the Delegation Type range. 2.2. Relationship with NS and DS Records The use of DS and delegation point NS records is orthogonal to the use of Delegation Types. NS and DS records MAY coexist with Delegation Types. Although the DS RR type has similar semantics, it is not classified as a Delegation Type for the purposes of this document. 3. Delegation Types [RFC6895] lists three subcategories of RR type numbers: data TYPEs, QTYPEs, and Meta-TYPEs. This specification adds a fourth subcategory: Delegation Types. Delegation Types are DNS CLASS independent. Section 9.3 requests IANA to allocate the range 0xF000-0xF1FF (61440-61951) for Delegation Types. The Delegation Type range is divided into four segments. The segment in which a Delegation Type is allocated determines its handling in referral responses. The segmentation allows the intended referral behavior of a Delegation Type to be determined from its type code, avoiding the need to define or maintain separate per-type signaling for these behaviors. Decimal Hex Segment Description 61440- 0xF000- NS-Omitting Delegation Types 61567 0xF07F 61568- 0xF080- NS-Preserving Delegation Types 61695 0xF0FF 61696- 0xF100- On-Demand Delegation Types 61935 0xF1EF 61936- 0xF1F0- Private Delegation Types 61951 0xF1FF Arends, et al. Expires 21 March 2027 [Page 4] Internet-Draft DELEXT September 2026 3.1. NS-Omitting Delegation Types The NS-Omitting Delegation Type segment contains types for delegation mechanisms that provide sufficient information for processing a delegation without the NS RRset. Separating these types allows referral responses to avoid carrying redundant delegation information, thereby reducing response size. 3.2. NS-Preserving Delegation Types The NS-Preserving Delegation Type segment contains types for delegation mechanisms that are used alongside the existing NS RRset. These types supplement, rather than replace, the delegation information provided by the NS RRset. 3.3. On-Demand Delegation Types The On-Demand Delegation Type segment contains types that are not ordinarily needed in referral responses and can instead be queried for explicitly. This avoids increasing referral response sizes with information that is not required during normal delegation processing. 3.4. Private Delegation Types The Private Delegation Type segment is reserved for Private Use as defined in [RFC8126]. Private Delegation Types have the same referral behavior as NS-Preserving Delegation Types. This allows Private Delegation Types to be used in referral responses without replacing the delegation information provided by the NS RRset. 3.5. Updates to Allocation Policy [RFC6895] establishes the allocation policy for DNS Resource Record type numbers. (@crit) defines the criteria for determining whether an RR type is eligible for allocation as a Delegation Type. Section 9.4 specifies additional Expert Review criteria for allocation requests within the range 0xF000-0xF1EF. 3.5.1. Criteria for Delegation Type Allocation A Resource Record type is eligible for allocation as a Delegation Type, rather than as a Data Type, only if all of the following conditions are met: * The RR type is intended to appear at a delegation point as authoritative data in the delegating zone, in a manner analogous to the DS record as defined in [RFC4034]. Arends, et al. Expires 21 March 2027 [Page 5] Internet-Draft DELEXT September 2026 * The RR type carries information associated with the delegation that is intended to be processed by a resolver. This includes information used while following the delegation, as well as information that may be queried for separately when needed. * The RR type is not intended to appear as authoritative data within the delegated zone itself. RR types that do not meet all of these criteria MUST NOT be allocated from the Delegation Types range. 4. Name Server Requirements Delegation-Extension-aware name servers MUST copy the value of the EDNS(0) DE flag from the request to the response. When the value of the EDNS(0) DE flag is 0, the server behaves as a server that does not implement this specification, i.e., Delegation Types are processed as ordinary Data Types. 4.1. Including Delegation Types in a Referral Response When the DE flag is set to 1, an authoritative server constructs a referral response according to the segment of each Delegation Type RRset present at the delegated name. NS-Omitting, NS-Preserving, and Private Delegation Type RRsets present at the delegated name MUST be included in the referral response. On-Demand Delegation Type RRsets MUST NOT be included unless explicitly queried for, as described in Section 4.2. If one or more NS-Omitting Delegation Type RRsets are present at the delegated name, the server MUST NOT include the NS RRset in the referral response, regardless of whether NS-Preserving or Private Delegation Type RRsets are also present and regardless of whether QTYPE=NS. If no NS-Omitting Delegation Type RRsets are present, the server MUST include the NS RRset in the referral response. The presence of an NS-Omitting Delegation Type takes precedence over the NS-preserving behavior of an NS-Preserving Delegation Type. For DNSSEC-signed zones, the response MUST include DNSSEC proof of the existence or non-existence of Delegation Type RRsets at the delegated name. Arends, et al. Expires 21 March 2027 [Page 6] Internet-Draft DELEXT September 2026 Note that when the DE flag is clear (i.e., set to 0), and no NS RRset exists at a delegation point, there is no referral from the perspective of a non-Delegation-Extension-aware resolver and the server returns a negative response. The server SHOULD include the Delegation Extension Required INFO-CODE 34 ("New Delegation Only") Extended DNS Error [RFC8914] specified in [I-D.ietf-deleg] absent a local policy requiring otherwise. If future Delegation Types require extended error codes with new semantics, those Delegation Types must define their own codes. 4.1.1. Compact Denial of Existence This document updates Compact Denial of Existence (CDOE) [RFC9824]. For CDOE enabled servers, the negative response required above is an exception to the CDOE method, i.e., it MUST be generated as a conventional Name Error proof ([RFC4035], or [RFC5155] for NSEC3) rather than as an NXNAME-based NODATA response, and it MUST be returned regardless of whether the query sets the Compact Answers OK (CO) flag [RFC9824]. For an NSEC zone, a single NSEC record whose owner name matches the delegation point satisfies both aspects of the Name Error proof at once — it covers both the queried name and the wildcard at the closest encloser — while its Type Bit Maps field conveys the Delegation Type(s) present at the delegation point. For an NSEC3 zone, the proof is the usual closest-encloser construction of [RFC5155]: the NSEC3 record matching the delegation point (whose Type Bit Map conveys the Delegation Type(s) present there), the NSEC3 record covering the next closer name, and the NSEC3 record covering the source of synthesis (wildcard) at the closest encloser. Unlike the NSEC case, these are in general three distinct records, because NSEC3 hashing does not preserve the name hierarchy. Returning an NXNAME-based response matching the queried name would not convey the presence of Delegation Types at the delegation point and would prevent the downgrade detection described in Section 6.2 and Section 8.4. 4.2. Explicit Queries for Delegation Types When the DE flag is set to 1, a query for a Delegation Type MUST result in an authoritative answer if the queried Delegation Type exists, or a NODATA response (AA flag set, RCODE=0, empty answer section). Arends, et al. Expires 21 March 2027 [Page 7] Internet-Draft DELEXT September 2026 Note that when the DE flag is clear, presence of an NS RRset at the delegation point occludes other types, as clarified in [RFC2136] Section 7.18, i.e., if an NS RRset exists at the delegation point, a query for a Delegation Type will result in a referral containing the NS RRset, regardless of whether the queried Delegation Type RRset exists at that delegation point. 4.3. Queries for type ANY Queries for type ANY where the QNAME matches a delegation point with Delegation Types present MUST behave the same way as if a DS record was present at the delegation point. 4.4. Delegation Types at a Wildcard Domain Name Wildcard expansion defined in [RFC4592] does not create delegation points, as it was left undefined. Consequently, a wildcard owner name MUST NOT have Delegation Types. 5. Resolver Requirements 5.1. The EDNS(0) DE Flag EDNS(0) [RFC6891] defines 16 bits as extended flags in the OPT record. These bits are encoded into the TTL field of the OPT record. +0 (MSB) +1 (LSB) 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | EXTENDED-RCODE | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | DO| CO| DE| Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 1: OPT Record TTL Field with DE Flag The descriptions of the EXTENDED-RCODE, VERSION, DO, and Z are provided in [RFC6891] Section 6.1.3. The description of the CO flag is provided in [RFC9824]. Section 9.1 requests IANA to assign the Delegation Extensions (DE) flag to Bit 2. To indicate Delegation Types support, a resolver sets the Delegation Extensions flag to 1 in the EDNS(0) Flags field when sending a DNS request message. Arends, et al. Expires 21 March 2027 [Page 8] Internet-Draft DELEXT September 2026 A Delegation-Extension-aware recursive resolver that receives a query with the DE flag set to 1 MUST set the DE flag to 1 in its response to indicate that Delegation Types are supported. 5.2. Referrals The presence of one or more NS-Omitting, NS-Preserving, or Private Delegation Type RRsets in the Authority section identifies the response as a referral. When one or more NS-Omitting Delegation Type RRsets are present in a referral, the resolver MUST use the information provided by those Delegation Type RRsets to process the delegation. Any NS records present in the referral MUST be ignored and MUST NOT be validated or cached. When no NS-Omitting Delegation Type RRsets are present, the resolver MUST use the NS RRset to process the delegation. NS-Preserving and Private Delegation Type RRsets present in the referral supplement the delegation information provided by the NS RRset. The purpose of ignoring NS records in the presence of NS-Omitting Delegation Types is to avoid leakage of DNS messages over unencrypted transport (i.e., Do53) when servers, indicated by Delegation Types, fail to respond. When a signed Delegation Type RRset is the result of a wildcard domain name expansion, the delegation MUST NOT be used. Treat such delegation point as if all servers were unusable. The label counter in the RRSIG RDATA will be less than the number of labels observed in the owner name. When the referral contains no Delegation Type RRsets, the resolver MUST use NS records. Note that DNSSEC can prove the presence and absence of Delegation Types at a delegation. 5.3. Algorithm for "Finding the Best Servers to Ask" This document updates instructions for finding the best servers to ask, covered in [RFC1034] Section 5.3.3 and [RFC6672] Section 3.4.1 with the text "2. Find the best servers to ask." These instructions were informally updated by [RFC4035] Section 4.2 for the DS RR type. This document applies the behavior for DS RR types to Delegation Types. Arends, et al. Expires 21 March 2027 [Page 9] Internet-Draft DELEXT September 2026 Each delegation level can have a mixture of Delegation Types and NS RR types, and Delegation-Extension-aware resolvers MUST be able to follow chains of delegations which combine both types in arbitrary ways. The terms SNAME and SLIST used here are defined in [RFC1034] Section 5.3.2: * SNAME is the domain name we are searching for. * SLIST is a structure which describes the name servers and the zone which the resolver is currently trying to query. This document defines SLIST to be a set. Each individual value MUST be represented only once in the final SLIST even if it was encountered multiple times during SLIST construction. Neither [RFC1034] nor this document define how a resolver uses SLIST. They only define how to populate it. A Delegation-Extension-aware resolver's SLIST needs to be able to hold multiple types of information, delegations defined by NS RRset and delegations defined by Delegation Type RRsets. Delegations can create cyclic dependencies and/or lead to duplicate entries which point to the same server. Resolvers need to enforce suitable limits to prevent runaway processing even if someone has incorrectly configured some of the data used to create an SLIST. This is the same recommendation to bound the amount specified in [RFC1034] Section 5.3.3. Step 2 of [RFC1034] Section 5.3.3 is "2. Find the best servers to ask." For Delegation-Extension-aware resolvers, this description becomes: ===== 2. Find the best servers to ask: 2.1. Determine deepest possible zone cut which can potentially hold the answer for a given (query name, type, class) combination as follows: 2.1.1. Start with SNAME equal to QNAME. Arends, et al. Expires 21 March 2027 [Page 10] Internet-Draft DELEXT September 2026 2.1.2. If QTYPE is a type that is authoritative at the delegation point (DS or the range defined in this document), remove the leftmost label from SNAME. For example, if the QNAME is "test.example." and the QTYPE is a Delegation Type or DS, set SNAME to "example.". 2.2. Look for locally available Delegation Types and NS RRsets, starting at current SNAME. 2.2.1. For a given SNAME, check for the existence of NS-Omitting Delegation Type RRsets. If they exist, the resolver MUST use their content to populate SLIST. However, if the Delegation Type RRsets are known to exist but are unusable (for example, if it is found in DNSSEC BAD cache, or content of individual RRs is unusable for any reason), the resolver MUST NOT use an NS RRset; the resolver MUST treat this case as if SLIST is populated with unreachable servers. 2.2.2. If a given SNAME is proven to not have NS-Omitting Delegation Type RRsets but does have an NS RRset, the resolver MUST copy the NS RRset into SLIST. The resolver MUST process any NS-Preserving or Private Delegation Type RRsets according to the specification defining those types. 2.2.3. If a given SNAME is proven to not have any Delegation Type RRsets or an NS RRset, remove the leftmost label from SNAME and go back to step 2.2, using the newly shortened SNAME. Note the existence of these RRsets stops this algorithm even if the SLIST is empty or if servers referenced by SLIST are unusable for any reason. ===== The rest of Step 2's description in [RFC1034] Section 5.3.3 is not affected by this document. Note that a query for QNAME="." and QTYPE=DS (or a Delegation Type) is nonsensical, as there is no zone that delegates to the root zone. 6. DNSSEC Requirements In a DNSSEC-signed zone, Delegation Type RRsets MUST be signed. To avoid a downgrade attack, where the Delegation Type RRsets, NSEC (or NSEC3) RRsets and their signatures can be replaced by unsigned NS records, a secure signal in the form of a DNSKEY flag is introduced. Arends, et al. Expires 21 March 2027 [Page 11] Internet-Draft DELEXT September 2026 See Section 8.2.1 for the specific Threat Model. This secure signal indicates that NSEC or NSEC3 records MUST be present in a referral response. 6.1. The DNSKEY-ADT Flag The DNSKEY Flags field consists of 16 bits shown in Figure 2. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | |ZON|REV| |ADT|SEP| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 2: DNSKEY Flags Field The descriptions of the ZONE (ZON) and Secure Entry Point (SEP) flags are provided in [RFC4034]. The description of the REVOKE (REV) flag is provided in [RFC5011]. Section 9.2 requests IANA to assign the DNSKEY-ADT flag to bit 14. When set to 1, it indicates to a validator that a referral MUST contain an NSEC or NSEC3 record to prove the presence or absence of types for the delegated name. 6.2. Validating a Referral On receiving a referral from a DNSSEC-signed delegating zone, a validating resolver MUST determine the authenticated state of the ADT flag from a validated DNSKEY RRset for that zone. When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY RRset of the delegating zone, the validator MUST check the NS- Omitting, NS-Preserving, and Private Delegation Type RRsets in the Authority section of the referral against the Type Bit Maps of the NSEC or NSEC3 record that matches the delegated name. If any are absent, the referral MUST be considered tampered with, and the response MUST be ignored. On-Demand Delegation Types indicated by the Type Bit Maps are not required to be present in a referral response. When the DNSKEY-ADT flag is clear, this consistency check does not apply. To be explicit, it means that a positive response with a DELEG RRset SHOULD NOT be treated as DNSSEC-bogus due to a clear ADT flag. The resolver processes the referral according to the procedures defined in Section 5. Arends, et al. Expires 21 March 2027 [Page 12] Internet-Draft DELEXT September 2026 6.3. Clarifications on Nonexistence Proofs This document updates [RFC6840] Section 4.1 to include "NS or Delegation Types" in the type bitmap as indication of a delegation point, and generalizes applicability of ancestor delegation proof to all RR types that are authoritative at a delegation point. The text in that section is updated as follows: An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: * the NS and/or Delegation Type bits set, * the Start of Authority (SOA) bit clear, and * a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that original owner name, other than types authoritative at the delegation point (DS and Delegation Types), and all RRs below that owner name regardless of type. 6.4. Insecure Delegation Proofs This document updates [RFC6840] Section 4.4 to include securing delegation point RRsets. The first paragraph of that section is updated to read: [RFC4035] Section 5.2 specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap; this was clarified in [RFC6840] Section 4.1. This document updates [RFC4035] and [RFC6840] to specify that the validator MUST check for the presence of the NS or Delegation Type bits in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation). Alternatively, the validator must make sure that the delegation with an NS record is covered by an NSEC3 RR with the Opt-Out flag set. Opt-Out is not applicable to delegations with Delegation Type RRsets as Delegation Type RRsets are authoritative at the delegation point. Arends, et al. Expires 21 March 2027 [Page 13] Internet-Draft DELEXT September 2026 7. Operational Considerations A security-aware stub resolver that is Delegation-Extension-aware MUST only use security-aware resolvers that are Delegation-Extension- aware. A Delegation-Extension-aware validating resolver that uses forwarders MUST only use Delegation-Extension-aware and security- aware forwarders. Otherwise DNSSEC-secure zones might fail to validate and DNSSEC-insecure zones might observe inconsistent answers. 8. Security Considerations This section discusses the security properties of the mechanisms defined in this document, identifies attack surfaces, and describes the mitigations provided or required. 8.1. Threat Model The threat model assumed by this document includes an on-path attacker capable of intercepting, modifying, dropping, and injecting DNS messages in transit between a resolver and an authoritative name server. Off-path attackers capable of response forgery (e.g., via birthday attacks on UDP) are also considered. Attackers may attempt to cause a resolver to use unencrypted transport, to resolve names incorrectly, or to be denied service entirely. 8.2. Downgrade Attacks Two classes of downgrade attack are relevant to this specification. 8.2.1. Stripping of Delegation Types from Referrals An on-path attacker may remove NS-Omitting Delegation Type RRsets and associated NSEC or NSEC3 records from a referral response, leaving only unsigned NS records. A resolver that accepts such a modified referral would proceed to resolve the delegated name using the NS RRset, potentially using unencrypted transport and thereby defeating security properties provided by the NS-Omitting Delegation Types. The DNSKEY-ADT flag defined in Section 6.1 provides a mitigation against this attack for validating resolvers. When the ADT flag is set in any DNSKEY of the delegating zone's DNSKEY RRset, a validating resolver MUST verify that the referral contains NSEC or NSEC3 records proving the presence or absence of Delegation Types for the delegated name. A referral lacking this proof MUST be treated as tampered with and MUST be ignored. Arends, et al. Expires 21 March 2027 [Page 14] Internet-Draft DELEXT September 2026 This mitigation is effective only when all of the following conditions hold: * The delegating zone is DNSSEC-signed. * The ADT flag is set in the delegating zone's DNSKEY RRset. * The resolver performs DNSSEC validation. * The resolver enforces the ADT requirement as specified in Section 6.2. Operators of zones that publish Delegation Types MUST set the ADT flag in their DNSKEY RRset to ensure that validating resolvers can detect this form of tampering. Zones that have not set the ADT flag provide no cryptographic protection against this attack. 8.2.2. Stripping of the DE Flag from Queries The DE flag is carried in the EDNS(0) OPT record of query messages sent by resolvers. An on-path attacker may remove this flag from a query before it reaches the authoritative name server. A server that receives a query with the DE flag clear will respond without Delegation Type RRsets, returning NS records only. However, when the ADT flag is set in the delegating zone's DNSKEY RRset, a Delegation-Extension-aware validating resolver expects that NSEC or NSEC3 proof of Delegation Types accompany any referral from that zone. This obligation is established by the DNSKEY, not negotiated per-query via the DE flag. Consequently, a referral response lacking the required NSEC or NSEC3 records MUST be rejected by a validating resolver, whether or not the DE flag was stripped from the outgoing query. In this case, the ADT mechanism defeats the DE-flag-stripping attack. This mitigation is subject to the same conditions as those listed in Section 8.2.1: the delegating zone must be signed, ADT must be set, and the resolver must validate. In the absence of these conditions, no cryptographic protection against DE-flag-stripping is available, and the considerations in Section 8.5 apply. 8.2.3. Interaction Between Flag-Stripping Attacks The two downgrade attacks described above may be attempted in combination. An attacker who strips the DE flag from a query causes the authoritative name server to respond with NS records only and no Delegation Types. Without NS-Omitting Delegation Types in the response, the resolver cannot apply the NS-ignoring rule defined in Section 5.2, and would ordinarily follow the NS records to resolve the delegated name, potentially over unencrypted transport. Arends, et al. Expires 21 March 2027 [Page 15] Internet-Draft DELEXT September 2026 As described in Section 8.2.2, the ADT flag defeats this combined attack for validating resolvers in zones where ADT is set. The resolver's obligation to require NSEC or NSEC3 proof derives from the previously validated DNSKEY RRset, not from the contents of the referral itself. A referral containing only NS records, with no NSEC or NSEC3 proof, will be rejected regardless of whether Delegation Types were present. The residual risk in both Section 8.2.2 and this section therefore reduces to the same condition: zones in which ADT is not set, or in which DNSSEC is not deployed, provide no cryptographic protection against either attack. This is a deployment risk, addressed in Section 8.5. 8.3. Injection of Delegation Types Section 5.2 specifies that when NS-Omitting Delegation Type RRsets are present in a referral response, accompanying NS records are ignored. An attacker capable of injecting or forging a referral response could exploit this rule by introducing fabricated Delegation Type RRsets into the response, causing the resolver to ignore legitimate NS records and use only the attacker-supplied NS-Omitting Delegation Type RRsets, which may point to an attacker-controlled server. This attack is mitigated by DNSSEC. In a DNSSEC-signed zone, Delegation Type RRsets must be signed as specified in Section 6. A validating resolver will reject responses containing unsigned or incorrectly signed Delegation Type RRsets. In unsigned zones, no cryptographic protection against this attack is available. 8.4. Denial-of-Service via a Negative Response for non-Delegation- Extension-aware Resolvers Section 4.1 notes that when the DE flag is clear and no NS RRset exists for a referral, the authoritative name server must return a negative response. This behavior is intended to prevent a non- Delegation-Extension-aware resolver from exhausting other authoritative name servers for information it cannot act upon. An attacker may attempt to exploit this behavior by stripping the DE flag from a query directed at a zone that publishes only Delegation Types and no NS RRsets, causing the server to return a negative response for a name that legitimately exists. Arends, et al. Expires 21 March 2027 [Page 16] Internet-Draft DELEXT September 2026 However, a resolver that sets the DE flag expects NSEC or NSEC3 proof in any negative response, demonstrating that the queried name does not exist or that no Delegation Types are present at or above it. A bare negative response lacking such proof is therefore detectable by a validating resolver. When the ADT flag is set in the delegating zone's DNSKEY RRset, the resolver MUST reject a negative response that does not include the required NSEC or NSEC3 records, as the absence of proof indicates tampering. Authoritative name servers for a delegating zone that employ Compact Denial of Existence [RFC9824] MUST NOT satisfy this proof with an NXNAME-based response matching the queried name, because such a response omits the Delegation Type bits at the delegation point on which this detection relies. They MUST instead return a conventional Name Error proof as described in Section 4.1.1. As with the attacks described in Section 8.2, this mitigation depends on the delegating zone being DNSSEC-signed, ADT being set, and the resolver performing validation. In zones where these conditions do not hold, a DE-flag-stripping attack may result in a negative response that the resolver cannot distinguish from a legitimate one, causing a denial of service for the queried name. This residual risk is addressed in Section 8.5. Authoritative name servers SHOULD include an Extended DNS Error [RFC8914] code in negative responses returned when the DE flag is clear and no NS RRset exists, to assist in diagnosing misconfiguration or attack, absent a local policy requiring otherwise. 8.5. Partial Deployment and Transition Risks The mechanisms defined in this document are effective only when deployed end-to-end. During the transition period in which some resolvers, authoritative name servers, and zones have adopted this specification and others have not, a number of residual risks apply. The ADT flag provides protection against the downgrade attacks described in Section 8.2 only when the delegating zone is DNSSEC- signed, the ADT flag is set in the zone's DNSKEY RRset, and the resolver performs validation. In zones that publish Delegation Types but have not set the ADT flag in the DNSKEY RRset, or that are not DNSSEC-signed, no cryptographic protection against referral-stripping or DE-flag-stripping attacks is available. Zone operators that publish Delegation Types in signed zones are REQUIRED to set the ADT flag upon deployment. Zones relying on Delegation Types for security properties, such as encrypted transport, MUST be DNSSEC-signed. Arends, et al. Expires 21 March 2027 [Page 17] Internet-Draft DELEXT September 2026 9. IANA Considerations 9.1. The EDNS(0) DE Flag IANA is requested to assign Bit 2 in the "EDNS Header Flags (16 bits)" registry under the "Domain Name System (DNS) Parameters" registry group to "DE Delegation Extensions", available at https://www.iana.org/assignments/dns-parameters with this document as the Reference as follows: Bit Flag Description Reference Bit 2 DE Delegation Extensions This-document 9.2. The DNSKEY-ADT Flag IANA is requested to assign bit 14 of the 16-bit flags field in the "DNSKEY RR Flags" registry under the "DNSKEY FLAGS" registry group available at https://www.iana.org/assignments/dnskey-flags/dnskey- flags.xhtml as follows: Number Description Reference 14 Authoritative Delegation Types This-document 9.3. Changes to the DNS Parameters RR Types Registry IANA is requested to change reservations in the "Resource Record (RR) TYPEs" registry under the "Domain Name System (DNS) Parameters" registry group, available at https://www.iana.org/assignments/dns- parameters with this document as the Reference. Decimal Hex Registration Procedures Note 61440- 0xF000- Expert Review or NS-Omitting 61567 0xF07F Standards Action Delegation TYPEs 61568- 0xF080- Expert Review or NS-Preserving 61695 0xF0FF Standards Action Delegation TYPEs 61696- 0xF100- Expert Review or On-Demand 61935 0xF1EF Standards Action Delegation TYPEs 61936- 0xF1F0- Private Use Private 61951 0xF1FF Delegation TYPEs Allocation requests in the range 0xF000-0xF1EF require Expert Review or Standards Action. The allocation MUST be made from the segment corresponding to the referral behavior of the Delegation Type as defined in Section 3. The Designated Experts for this range are drawn from the RFC6895 Experts Pool. Arends, et al. Expires 21 March 2027 [Page 18] Internet-Draft DELEXT September 2026 9.4. Additional Expert Review Criteria In addition to the general Expert Review criteria established by [RFC6895], the Designated Experts should evaluate allocation requests for Delegation Types against the criteria in Section 3.5.1. The Designated Experts should also consider: * Whether the requested segment is appropriate for the referral behavior of the proposed Delegation Type. A type that provides sufficient information to process a delegation without the NS RRset should be allocated from the NS-Omitting segment. A type that supplements the NS RRset should be allocated from the NS- Preserving segment. A type that is not ordinarily required in referral responses should be allocated from the On-Demand segment. * Whether the proposed Delegation Type requires protocol modifications beyond those defined in this document, and if so, whether those modifications have been or are being specified in an appropriate Standards Track document. * Whether the proposed Delegation Type can be processed safely by Delegation-Extension-aware implementations that do not specifically implement the proposed type, in particular with respect to the requirements in Section 5.2 and Section 4.1. * Whether the security properties of the proposed Delegation Type are compatible with the DNSSEC signing requirements of Section 6, and whether any additional security considerations apply. The Designated Experts may approve allocation requests accompanied by a stable, publicly available specification that need not be an RFC, provided that the specification is sufficiently detailed to allow independent interoperable implementation. Allocation requests for Delegation Types that introduce new protocol behaviors or that interact with the mechanisms defined in Section 4, Section 5, or Section 6 of this document must be accompanied by, or integrated into, a Standards Track document. 10. Acknowledgments This document is heavily based on past work done by Tim April in [I-D.tapril-ns2] and thanks are extended to those who helped, including: John Levine, Erik Nygren, Jon Reed, Ben Kaduk, Mashooq Muhaimen, Jason Moreau, Jerrod Wiesman, Billy Tiemann, Gordon Marx, and Brian Wellington. Arends, et al. Expires 21 March 2027 [Page 19] Internet-Draft DELEXT September 2026 Work on the Delegation Extensions protocol was started at IETF 118 Hackathon. Hackathon participants: Christian Elmerot, David Blacka, David Lawrence, Edward Lewis, Erik Nygren, George Michaelson, Jan Včelák, Klaus Darilion, Libor Peltan, Manu Bretelle, Peter van Dijk, Petr Špaček, Philip Homburg, Ralf Weber, Roy Arends, Shane Kerr, Shumon Huque, Vandan Adhvaryu, Vladimír Čunát, Andreas Schulze. Other people joined the effort after the initial hackathon: Ben Schwartz, Bob Halley, Paul Hoffman, Miek Gieben, Ray Hunter, Håvard Eidnes, Ted Hardie, Michael Richardson, Florian Obser, Evan Hunt, Peter Thomassen. The idea of allocating a range of delegation types was proposed by Petr Špaček [I-D.peetterr-dnsop-parent-side-auth-types]. His contribution is rewarded by listing him as an author so he can take equal parts credit and blame. 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, . Arends, et al. Expires 21 March 2027 [Page 20] Internet-Draft DELEXT September 2026 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Arends, et al. Expires 21 March 2027 [Page 21] Internet-Draft DELEXT September 2026 [RFC9824] Huque, S., Elmerot, C., and O. Gudmundsson, "Compact Denial of Existence in DNSSEC", RFC 9824, DOI 10.17487/RFC9824, September 2025, . 11.2. Informative References [I-D.ietf-deleg] Špaček, P., Weber, R., and Lawrence, "Extensible Delegation for DNS", Work in Progress, Internet-Draft, draft-ietf-deleg-11, 23 July 2026, . [I-D.peetterr-dnsop-parent-side-auth-types] van Dijk, P. and P. Špaček, "Parent-side authoritative DNS records for enhanced delegation", Work in Progress, Internet-Draft, draft-peetterr-dnsop-parent-side-auth- types-01, 10 December 2024, . [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, . Authors' Addresses Roy Arends ICANN Guernsey Email: roy.arends@icann.org Peter van Dijk PowerDNS Den Haag Netherlands Email: peter.van.dijk@powerdns.com Petr Špaček ISC Brno Czech Republic Arends, et al. Expires 21 March 2027 [Page 22] Internet-Draft DELEXT September 2026 Email: pspacek@isc.org Arends, et al. Expires 21 March 2027 [Page 23]