I am the assigned ART-ART reviewer for this draft. The Art Area
Review Team (ART-ART) reviews all IETF documents being processed
by the IESG.  Please treat these comments just
like any other last call comments.

Document: draft-ietf-dnsop-delext-08
Reviewer: Jiankang Yao
Review Date: 2026-07-11

Summary: Almost Ready.

This document specifies modifications to the DNS protocol to permit a range of Resource Record types at
delegation points. These modifications are proposed to design to maintain
compatibility with existing DNS resolution mechanisms. 

I think that this is a very big change to DNS.
DNS is very important to Internet. It needs very careful review from IETF.

One suggestion:
Section 4.1 specifies that authoritative servers omit NS RRsets and return only Delegation Type 
RRsets in referrals when DE=1. This introduces ambiguous caching behavior
 for recursive resolvers in mixed deployment environments:

A resolver may first receive a DE=1 referral for a zone (carrying Delegation Type RRsets, 
no NS records), which it caches normally. 
A subsequent DE=0 or DELEXT-unaware query for the identical zone will trigger a traditional referral containing NS RRsets, 
populating the resolver cache with NS data.

Section 5.2 prohibits caching NS records obtained from DE=1 referrals,
 but the draft provides no clear rules governing NS records retrieved 
via DE=0 queries or DELEXT-unaware queries that coexist with cached Delegation Type RRsets for the same name. 

Since most real-world DNS clients may continue to send DE=0 or DELEXT-unaware query queries 
long after DELEXT deployment, the specification needs additional text to define resolver cache handling of NS RRsets.


One Question: Is this Potential DoS vulnerability from no cached NS fallback under DE=1?
 
Section 4.1 mandates authoritative servers omit NS RRsets in DE=1 referrals, 
and Section 5.2 forbids resolvers from caching NS records associated with DE=1 delegations.

If a DE=1 referral’s Delegation Type data fails to yield usable resolution endpoints for any reason, 
the resolver holds no cached NS fallback records for the zone example.com.
 The DNS clients will try and try again since they can not get the right DNS resolution of exaample.com.

 Do they open a denial-of-service attack?