[art] draft-ietf-dnsop-delext-08 ietf last call Artart review

[Jiankang Yao via Datatracker <[e-mail]>]

Document: draft-ietf-dnsop-delext
Title: DNS Protocol Modifications for Delegation Extensions
Reviewer: Jiankang Yao
Review result: Almost Ready

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?