Thanks for catching this, I’ve added the following text to section 2.1: 2.1. Updates to Allocation Policy
[RFC6895] establishes the allocation policy for DNS Resource Record
type numbers and defines the Expert Review process governing that
allocation. This section updates that policy to account for the
Delegation Types subcategory introduced in Section 2 and specifies
the criteria that apply to allocation requests within the ranges
0xF000-0xF1EF and 0xF1F0-0xF1FF.
2.1.1. Criteria for Delegation Type Allocation
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, prior to
sending queries to the authoritative servers for 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 SHOULD be allocated
from the existing Data Types range in accordance with [RFC6895] and
MUST NOT be allocated from the Delegation Types range.
The fact that a record type may be useful in the context of
delegation 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.
2.1.2. Expert Review Procedure
Allocation requests in the range 0xF000-0xF1EF require Expert Review
or Standards Action, as specified in Section 2. The Designated
Experts for this range are drawn from the RFC6895 Experts Pool.
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 2.1.1. The
Designated Experts SHOULD 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 3.2 and Section 4.1.
* Whether the security properties of the proposed Delegation Type
are compatible with the DNSSEC signing requirements of Section 5,
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 3, Section 4, or
Section 5 of this document SHOULD be accompanied by, or integrated
into, a Standards Track document.
2.1.3. Private Use Range
The range 0xF1F0-0xF1FF is reserved for Private Use in accordance
with [RFC8126]. Values in this range MUST NOT appear in the global
DNS and MUST NOT be used in any context where interoperability with
implementations outside a private network is required. Private Use
values are not subject to Expert Review and will not be registered by
IANA.
> On 4 May 2026, at 22:21, S Moonesamy <[email protected]> wrote:
>
> Hi Tim, Ondrej,
> At 01:02 PM 04-05-2026, Tim Wicinski wrote:
>> I had a question on the "Security Considerations" section
>>
>> This section discusses security considerations, including downgrade
>> attacks and resolver behavior. Further details will be added.
>>
>> Do we have any idea when this will come together?
>
> I went through the draft-ietf-dnsop-delext-02. Section 2.1 has the following
> sentence:
>
> "This section is to be written with guidance from the RFC6895 Experts Pool."
>
> The draft looks incomplete.
>
> Regards,
> S. Moonesamy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
