IETF Last Call Review of draft-ietf-dnsop-delext-08
review-ietf-dnsop-delext-08-secdir-lc-eastlake-2026-07-14-00

Hi,



I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the

IESG. These comments were written primarily for the benefit of the

security area directors. Document editors and WG chairs should treat

these comments just like any other last call comments.



The summary of the review is Ready with Issues.



This draft defines a category of DNS Resource Records (RRs) to appear

at delegation points and be authoritative in the parent while

analogous to the DS RR and also specifies their handling. A range of RR
types is reserved.



Security

--------



This draft has an excellent and, as far as I can see, complete

Security Considerations Section! The threat model is stated

explicitly, the attacks are enumerated, and the residual-risk analysis

is clear about the limits of protection. That is uncommon and

commendable.



Issues

------



These are really just questions:



Is a statement needed to the effect that, to be secure, a resolver

always needs to have obtained, validated, and be holding the DNSKEY

RRset with ADT flag from X before following a referral from X?



Is there a need to clearly state what a resolver does if a zone is

signed and has Delegation Types but whose DNSKEY does not have ADT

set?



Should the draft point out that it makes unsigned zones a bit less

secure from an injection attack? Currently injecting a referral

competes with the legitimate answer but by requiring NS RRs to be

ignored if there are Delegation Types, an injection can cause active

discard of legitimate NS RRs.



The threat model talks about resolver to authoritative name server but

not so much about stub to recursive or resolver to forwarder. I think

these are taken care of, but this threat aspect could be clearer.



Nits

----



Acknowledgements: contains an ellipsis that should probably be

replaced with a period.



Feel free to ignore the following items which are just my opinions:



Consider adding bit numbers at the top of Figure 1 as in Figure 2.



It seems more complex than necessary to say, in Section 3, that

0xF000-0xF1EF and 0xF1F0-0xF1FF are for Delegation Types. The only

difference is the assignment policy which is spelled out elsewhere. I

would just say that 0xF000-0xF1FF are allocated for Delegation

Types. Listing the two contiguous ranges in Section 3.1 seems OK

although probably "Section 3.1.1 updates that policy..." -> "Section

3.1.1 and Section 3.1.2 update that policy...".



Section 5.2, 2nd paragraph: "all information" -> "all the

information"



Thanks,

Donald

===============================

 Donald E. Eastlake 3rd

 2386 Panoramic Circle, Apopka, FL 32703 USA

 d3e3e3@gmail.com