[DNSOP] Re: [Ext] draft-ietf-dnsop-delext-08 ietf last c all Artart review

> On 11 Jul 2026, at 07:06, Jiankang Yao via Datatracker <[email protected]> wrote:
> 
> 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.

Dear Jiankang Yao, thank you for your review.

I agree. This is a big change to the DNS, and I appreciate the call for careful review from the 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.

A Delegation-Extension-aware resolver consistently sends DNS requests with DE=1. There is no scenario where it sends subsequent requests with DE=0.

> 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.

A Delegation-Extension-aware resolver has either NS (i.e. there are no DELEXT records for the delegation) or DELEXT records cached. 

> 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.

I’m afraid that the scenario you’ve described is not possible. EDNS information is not transient but hop by hop. A DE=0 request (or DE=1 for that matter) from a stub resolver has no influence on what the receiving resolver or forwarder sets in EDNS DE flags on subsequent upstream DNS requests.

> 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,

It omits NS RRsets when DELEXT types are present. When there are no DELEXT types present, the authoritative server includes NS records.

> and Section 5.2 forbids resolvers from caching NS records associated with DE=1
> delegations.

That is correct.

> 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.

That is correct. Section 5.2 goes on to explain why: 

"The purpose of this restriction is to avoid leakage of DNS messages over unencrypted transport (i.e., Do53) when servers, indicated by Delegation Types, fail to respond."

> The DNS clients will try and try again since they can not get the right DNS
> resolution of exaample.com.

If the DNS client is a stub resolver, it will receive a SERVFAIL response from the Delegation-Extension-aware resolver. This is no different when a non-Delegation-Extension-aware resolver receives unusable NS records.

> Do they open a denial-of-service attack?

I do not see how. At least not worse than a traditional deployment of unreachable NS delegation points.

Happy to discuss further, if I’m missing something.

Warmly,

Roy

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]