DNS Protocol Modifications for Delegation Extensions
draft-ietf-dnsop-delext-12
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Roy Arends , Peter van Dijk , Petr Špaček | ||
| Last updated | 2026-10-29 (Latest revision 2026-10-05) | ||
| Replaces | draft-arends-dnsop-delext, draft-peetterr-dnsop-parent-side-auth-types | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Ondřej Surý | ||
| Shepherd write-up | Show Last changed 2026-07-07 | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Mohamed Boucadair | ||
| Send notices to | ondrej@dns.rocks | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-dnsop-delext-12
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: 8 April 2027 ISC
5 October 2026
DNS Protocol Modifications for Delegation Extensions
draft-ietf-dnsop-delext-12
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 8 April 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 8 April 2027 [Page 1]
Internet-Draft DELEXT October 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 8 April 2027 [Page 2]
Internet-Draft DELEXT October 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 8 April 2027 [Page 3]
Internet-Draft DELEXT October 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 8 April 2027 [Page 4]
Internet-Draft DELEXT October 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 8 April 2027 [Page 5]
Internet-Draft DELEXT October 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 8 April 2027 [Page 6]
Internet-Draft DELEXT October 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 8 April 2027 [Page 7]
Internet-Draft DELEXT October 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 8 April 2027 [Page 8]
Internet-Draft DELEXT October 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 8 April 2027 [Page 9]
Internet-Draft DELEXT October 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 8 April 2027 [Page 10]
Internet-Draft DELEXT October 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 8 April 2027 [Page 11]
Internet-Draft DELEXT October 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 for Authoritative Delegation Types (ADT)
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 8 April 2027 [Page 12]
Internet-Draft DELEXT October 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 8 April 2027 [Page 13]
Internet-Draft DELEXT October 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 8 April 2027 [Page 14]
Internet-Draft DELEXT October 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 8 April 2027 [Page 15]
Internet-Draft DELEXT October 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 8 April 2027 [Page 16]
Internet-Draft DELEXT October 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 8 April 2027 [Page 17]
Internet-Draft DELEXT October 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 8 April 2027 [Page 18]
Internet-Draft DELEXT October 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 8 April 2027 [Page 19]
Internet-Draft DELEXT October 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, Carsten Strotmann.
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,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc2136>.
[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,
<https://www.rfc-editor.org/info/rfc4034>.
[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,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
Arends, et al. Expires 8 April 2027 [Page 20]
Internet-Draft DELEXT October 2026
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[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,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013,
<https://www.rfc-editor.org/info/rfc6840>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
Arends, et al. Expires 8 April 2027 [Page 21]
Internet-Draft DELEXT October 2026
[RFC9824] Huque, S., Elmerot, C., and O. Gudmundsson, "Compact
Denial of Existence in DNSSEC", RFC 9824,
DOI 10.17487/RFC9824, September 2025,
<https://www.rfc-editor.org/info/rfc9824>.
11.2. Informative References
[I-D.ietf-deleg]
Špaček, P., Weber, R., and D. C Lawrence, "Extensible
Delegation for DNS", Work in Progress, Internet-Draft,
draft-ietf-deleg-12, 4 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-deleg-
12>.
[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,
<https://datatracker.ietf.org/doc/html/draft-peetterr-
dnsop-parent-side-auth-types-01>.
[I-D.tapril-ns2]
April, T., "Parameterized Nameserver Delegation with NS2
and NS2T", Work in Progress, Internet-Draft, draft-tapril-
ns2-01, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tapril-
ns2-01>.
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 8 April 2027 [Page 22]
Internet-Draft DELEXT October 2026
Email: pspacek@isc.org
Arends, et al. Expires 8 April 2027 [Page 23]