[DNSOP] Re: draft-ietf-dnsop-delext-08 ietf last call Dnsdir review

> On 16 Jul 2026, at 02:09, Patrick Mevzek via Datatracker <[email protected]> wrote:
> 
> Document: draft-ietf-dnsop-delext
> Title: DNS Protocol Modifications for Delegation Extensions
> Reviewer: Patrick Mevzek
> Review result: Ready
> 
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the ADs.
> For more information about the DNS Directorate, please see
> https://wiki.ietf.org/en/group/dnsdir
> 
> After review, I do not have any substantiative comments, just maybe some nits:
> 
> 1)
> Maybe explicit documentation on behavior a resolver should implement
> if getting DE=1 back without having asked for that (as it means the answer is
> not as "usual"), which makes sense of course only for a resolver really parsing
> that EDNS but deciding for a given query to NOT send DE=1.

I’m not comfortable specifying behaviour in the event of non-compliant behaviour. Copying the value of the DE flag is a MUST.

> 2)
> Add in introduction that this specification also add a new EDE INFO-CODE
> (section 4.1) as all other changes are mentioned in the introduction except
> this one.

We have decided to refer to the DELEG draft for the EDE INFO-CODE, though I’ve added text to state that if new Delegation Types need different semantics, they should request new EDE INFO-CODEs

> 
> 3)
> "To avoid a downgrade attack, where the Delegation Type RRsets and NSEC (or
> NSEC3) records can be replaced by unsigned NS records, causing the resolver to
> use unencrypted transport"
> 
> This seems to equate "no signed records mean unencrypted transport" which might
> be true for only a very specific subset of delegation type RRsets, aka DELEG.
> I would maybe slightly rephrase the "causing" part as saying more generally
> that this in turn might/could force the resolver to ignore existing more secure
> options and transports in favor of going back to usual DNS over 53. But as one
> outcome possible, and not sole one nor always being the case anyway. [this is
> in fact correctly explained in §8.2.1 so maybe just reference it above?]

I will remove ", causing the resolver to use unencrypted transport” and add a reference to paragraph 8.2.1

> 
> 4) not sure, but in same section, maybe discuss consequences of adding ADT flag
> in existing DNSKEY vs just starting with new DNSKEY with the flag. As the flag
> value will impact the key tag, hence if changed on an existing key, key tag
> will change hence DS record needs to change, depending on which DNSKEY record
> it is (see next point)

I’m avoiding operation guidance for introducing the ADT flag, as it is specified specifically in the DELEG draft. Since operation guidance may change depending on the specific delegation type introduced, I’m afraid of ossifying operational work. 

> 
> 5) §4.2
> "When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY RRset
> of the delegating zone" In the spirit of focusing on delegation, shouldn't this
> be only on the KSK and not all keys? And in fact, shouldn't the ADT flag be
> irrelevant/ignored on ZSKs? If this has been already all discussed and decided,
> maybe just add a terse explanation (on why using all records and not a subset).

No. The Secure Entry Point flag (that differs between KSK and ZSK) is independent of the ADT flag. The SEP flag is a hint and not used for resolving nor validation.

> 6) "Authoritative servers SHOULD include an Extended DNS Error [RFC8914] code
> in NXDOMAIN responses" Reference §9.5 there?

See my response for point 2 above.

> 7)
> Appendix A is a bit short and not conveying really detailed examples
> but more just ideas.

That is correct, I’ll remove it.

> The document feels otherwise ready to be published.
> 
> I found the document well written and extensive for all interoperability details
> that are needed to be taken into account for an important DNS change like that,
> properly protected under explicit signaling to allow smooth upgrades.

Thanks for the review and the kind words

Warmly,

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