| Internet-Draft | DELEXT | June 2026 |
| Arends, et al. | Expires 31 December 2026 | [Page] |
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 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 31 December 2026.¶
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. 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.¶
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 that purpose, 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.¶
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.¶
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.¶
[I-D.ietf-deleg] specifies a new type (DELEG) that is authoritative at a delegation point and specifies protocol modifications to support DELEG. The present document generalizes those protocol modifications so they apply to a range of Delegation Types.¶
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.¶
[RFC6895] lists three subcategories of RR type numbers: data TYPEs, QTYPEs, and Meta-TYPEs. This specification adds a fourth subcategory: Delegation Types.¶
Section 9.3 requests IANA to allocate the ranges 0xF000-0xF1EF and 0xF1F0-0xF1FF for Delegation Types.¶
Appendix A describes potential services provided by Delegation Types.¶
[RFC6895] establishes the allocation policy for DNS Resource Record type numbers and defines the Expert Review process governing that allocation. Section 3.1.1 updates that policy to account for the Delegation Types subcategory and Section 9.4 specifies the criteria that apply to allocation requests within the ranges 0xF000-0xF1EF and 0xF1F0-0xF1FF.¶
A Resource Record type MUST be allocated as a Delegation Type, rather than as a Data Type, if and 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].¶
The RR type carries information that is intended to be acted upon by a resolver during the process of following a referral. This includes information used prior to sending queries to the authoritative servers for the delegated zone, or after the referral has been followed, such as material used to authenticate a DNSKEY in the delegated zone.¶
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.¶
A record type may be useful in the context of delegation, but that does not by itself qualify it for allocation as a Delegation Type. Record types that convey information useful to resolvers but that are intended to appear within a zone rather than at its delegation point in the delegating zone are Data Types and MUST be allocated accordingly.¶
Allocation requests in the range 0xF000-0xF1EF require Expert Review or Standards Action. The Designated Experts for this range are drawn from the RFC6895 Experts Pool.¶
Section 9.4 specifies additional Expert Review criteria.¶
The range 0xF1F0-0xF1FF is reserved for Private Use in accordance with [RFC8126]. Values in this range MUST NOT be published in zones intended for the public DNS and MUST NOT be used in any context where interoperability with implementations outside a private network is required.¶
Delegation-Extension-aware name servers MUST copy the value of the EDNS(0) DE flag from the request to the response.¶
When the DE flag is set to 1, the server includes Delegation Types in referrals and omits the NS RRset. When there are no Delegation Types for a referral, it includes the NS RRset. For DNSSEC-signed zones, the response MUST include DNSSEC proof of the presence or absence of Delegation Types for the delegated name.¶
When the DE flag is clear (i.e., set to 0), and no NS RRset exists for a referral, there is no facility for the resolver to continue resolving the delegated namespace. An NXDOMAIN (Name Error) MUST be returned in this case. Authoritative servers SHOULD include an Extended DNS Error [RFC8914] to clarify the reason, absent a local policy requiring otherwise.¶
The rationale is to prevent legacy resolvers from asking other authoritative name servers for the same information.¶
When the DE flag is set to 1, a query for a Delegation Type MUST result in an authoritative answer if the Delegation Type exists, or a NODATA response (AA flag set, RCODE=0, empty answer section).¶
When the DE flag is clear, a query for a Delegation Type MUST result in an authoritative answer if the Delegation Type exists. If the Delegation Type does not exist, the response MUST be a referral containing the NS RRset if an NS RRset exists, or a NODATA response if other Delegation Types exist.¶
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) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 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 Section 6.1.3 of [RFC6891]. 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.¶
Delegation Types are an opt-in extension to the DNS protocol. Their use is negotiated using the EDNS(0) DE flag, allowing existing DNS implementations to interoperate without modification.¶
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.¶
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.¶
The presence of one or more Delegation Types in the Authority section identifies the response as a referral.¶
Delegation Types, together with existing DNS protocol elements such as DS, provide all information required to process the delegation. Accordingly, NS records that appear in addition to Delegation Types MUST be ignored. These NS records MUST NOT be validated or cached.¶
The purpose of this restriction is to avoid leakage of DNS messages over unencrypted transport (i.e., Do53) when servers, indicated by Delegation Types, fail to respond.¶
When the referral contains no Delegation Types, the resolver MAY use NS records. Note that DNSSEC can prove the presence and absence of Delegation Types at a delegation.¶
In a DNSSEC-signed zone, Delegation Type RRsets MUST be signed.¶
To avoid a downgrade attack, where the Delegation Types and NSEC (or NSEC3) records can be replaced by unsigned NS records, causing the resolver to use unencrypted transport, a secure signal in the form of a DNSKEY flag is introduced. This secure signal indicates that NSEC or NSEC3 records MUST be present in a referral response.¶
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 description 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.¶
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 Delegation Types 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.¶
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.¶
This section discusses the security properties of the mechanisms defined in this document, identifies attack surfaces, and describes the mitigations provided or required.¶
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.¶
Two classes of downgrade attack are relevant to this specification.¶
An on-path attacker may remove Delegation Types 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 unencrypted transport, defeating the purpose of Delegation Types, such as those indicating encrypted transport parameters.¶
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.¶
This mitigation is effective only when all of the following conditions hold:¶
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.¶
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 DE clear will respond without Delegation Types, returning NS records only.¶
However, when the ADT flag is set in the delegating zone's DNSKEY RRset, a validating resolver expects that NSEC or NSEC3 proof of Delegation Types MUST 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-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.¶
The two downgrade attacks described above may be attempted in combination. An attacker who strips the DE flag from a query causes the authoritative server to respond with NS records only and no Delegation Types. Without 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.¶
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.¶
Section 5.2 specifies that when Delegation Types 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 a fabricated Delegation Type into the response, causing the resolver to ignore legitimate NS records and use only the attacker-supplied Delegation Type, 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 Types.¶
In unsigned zones, no cryptographic protection against this attack is available.¶
Section 4.1 specifies that when the DE flag is clear and no NS RRset exists for a referral, the authoritative name server must return an NXDOMAIN response. This behavior is intended to prevent a legacy resolver from exhausting other authoritative 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 NXDOMAIN for a name that legitimately exists.¶
However, a resolver that sets the DE flag expects NSEC or NSEC3 proof in any NXDOMAIN response, demonstrating that the queried name does not exist or that no Delegation Types are present at or above it. A bare NXDOMAIN 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 an NXDOMAIN response that does not include the required NSEC or NSEC3 records, as the absence of proof indicates tampering.¶
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-stripping attack may result in an NXDOMAIN 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 servers SHOULD include an Extended DNS Error [RFC8914] code in NXDOMAIN 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.¶
The mechanisms defined in this document are effective only when deployed end-to-end. During the transition period in which some resolvers, authoritative 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.¶
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¶
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¶
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 delegation TYPEs 61935 0xF1EF Standards Action 61936- 0xF1F0- Private Use private delegation TYPEs 61951 0xF1FF¶
In addition to the general Expert Review criteria established by [RFC6895], the Designated Experts MUST evaluate allocation requests for Delegation Types against the criteria in Section 3.1.1. The Designated Experts MUST also consider:¶
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.¶
This idea was initially proposed by Petr Špaček and independently by Paul Wouters.¶
Services provided by Delegation Types consist of information useful to a resolver when connecting to servers responsible for the delegated namespace. This can include, but is not limited to, secure transport parameters, policy information about zones, and DNSSEC security parameters.¶