| Internet-Draft | auth-delegation-types | September 2025 |
| Arends, et al. | Expires 20 March 2026 | [Page] |
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document describes modifications to the Domain Name System (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 20 March 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC4034] defines the Delegation Signer (DS) resource record as having a unique property: it resides at a delegation as authoritative data. Discussions and drafts within the DPRIVE, DNSOP, and DELEG working groups have highlighted interest in allowing additional types of data to be present at delegation points. This document reserves a range of Resource Record (RR) types allowed at delegations points and describes the protocol modifications for DNS implementations that support them.¶
To shield implementations that do not implement these modifications, a new EDNS(0) [RFC6891] option is introduced to indicate support for this range of RR types.¶
To protect against downgrade attacks, a new DNSKEY flag is introduced.¶
The term Extended Delegation types designates the set of RR types consisting of the range of RR types reserved in Section 2 of this document.¶
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.¶
The DELEG draft specifies a new resource record type (DELEG) that is authoritative at a delegation point and proposes protocol modifications to support DELEG.¶
The sole purpose of this document is to make sure that the protocol modifications are generic for a range of types instead of just a single record.¶
If the Working Group decides to separate the DELEG type specification from the protocol modifications needed to support Extended Delegations, we will incorporate all the necessary parts in this document.¶
If the Working Group decides to adopt the changes proposed in this specification into the DELEG draft, it is expected that these will be integrated in the DELEG specifications.¶
The use of DS and delegation point NS records is orthogonal to the use of Extended Delegation records. Both types MAY co-exist with Extended Delegation types.¶
Services provided by Extended Delegation types consist of information useful to a resolver when connecting to servers responsible for the delegated namespace. This can range from, but is not limited to, secure transport parameters, policy information about zones, DNSSEC security parameters, etc.¶
[RFC6895] contains three subcategories of RR type numbers: Data Types, Q-Types, and Meta-Types. This specification adds a fourth subcategory: Extended Delegation Types.¶
Considerations for the allocation of Extended Delegation Types are as follows:¶
Decimal Hexadecimal Registration Procedure 512-751 0x0200-0x02EF Expert Review or Standards Action 752-767 0x02F0-0x02FF Private Use¶
This section is to be written with guidance from the RFC6895 Experts Pool.¶
To indicate Extended Delegation support, the resolver sets the Delegation Extensions (DE) flag in the EDNS(0) Flags field when sending a DNS request message.¶
The DE flag is carried in the OPT RR TTL field.¶
+0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | EXTENDED-RCODE | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | DO| DE| Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+¶
Extended Delegation types in the authority section of a DNS response message indicate that the response contains a referral. Extended Delegation types are expected to contain all the information needed for a resolver to act on. Therefore, NS records that appear in addition to Extended 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 when servers, indicated by Extended Delegation types, fail to respond.¶
When no Extended Delegation types exist, the resolver can use NS records. Note that the use of DNSSEC can prove the presence and absence of Extended Delegation types for a delegation.¶
Extended Delegation-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, the server includes Extended Delegation types in referrals and ignores NS types. When there are no Extended Delegation types for a referral, it includes NS types. The proof of existence of types for the delegated name MUST be included.¶
When the DE flag is clear, and no NS records exist for a referral, there is no facility for the resolver to continue resolving the delegated namespace. A name error SHOULD be returned in this case. While this may seem counterintuitive, since the name does exist, it is the only response code that stops the resolver from asking other authoritative name servers for the same information. Authoritative servers SHOULD include an Extended DNS Error [RFC8914] to clarify the reason.¶
When the DE flag is set, a query for an Extended Delegation type SHOULD result in an authoritative answer when the Extended Delegation type exists, or a NODATA response (AA flag set, RCODE=0, empty answer section).¶
When the DE flag is clear, a query for an Extended Delegation type SHOULD result in an authoritative answer when the Extended Delegation type exists; in a referral with NS types when NS types exist, or in a NODATA response when other Extended Delegation types exist.¶
In a DNSSEC signed zone, Extended Delegation RRsets MUST be signed.¶
To avoid a downgrade attack, where the Extended Delegation types and NSEC (or NSEC3) records can be replaced by unsigned NS records to cause 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:¶
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | |Zon|Rev| |DE |SEP| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+¶
Bit 14 is the Delegation Extension (DE) flag. It indicates to a validator that a referral MUST contain an NSEC or NSEC3 record to prove presence or absence of types for the delegated name.¶
When the DNSKEY-DE flag is set in any DNSKEY from the DNSKEY RRset of the delegating zone, the validator MUST check the Extended 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.¶
This section discusses security considerations, including downgrade attacks and resolver behavior. Further details will be added.¶
IANA is requested to change reservations in the DNS Parameters RR types registry, with this document as the Reference.¶
This idea was initially proposed by Petr Spacek, and independently by Paul Wouters.¶