[dd] Re: [DNSOP] delext-12 vs. deleg-12 review

[Roy Arends <[e-mail]>]

> On 2 Nov 2026, at 09:11, Libor Peltan <[e-mail]> wrote:
> 
> Hi Roy,
> 
> thank you for your answer! Please find my reactions inline.
> 
> On 30. 10. 26 1:26, Roy Arends wrote:
>>> 1) I feel a lack of proper description of the situation when Delegation-Extension-unaware (DE=0) validating resolver queries a name at/below NS-Omitting type. It can believe it is a NODATA/NXDOMAIN proof.
>> 
>> Section 4.1:
>> 
>> Note that when the DE flag is clear (i.e., set to 0), and no NS RRset exists at a delegation point, there is no referral from the perspective of a non-Delegation-Extension-aware resolver and the server returns a negative response.
> 
> Well, draft-deleg has a pretty detailed and well-written Section 5.2.2.1 regarding this issue, together with useful examples in the Appendix, and some remarks here and there, e.g. through Section 6.
> 
> I think draft-delext shouldn't be missing those considerations, they might in fact be moved from draft-deleg to draft-delext. What do you think?

Will confer with deleg-authors.

>>> 2) From an implementer's perspective, the subranges of the Delegation Types range could be rearranged to be more handy:
>>>     - NS Preserving and Private types should be in adjacent ranges (to form a single bigger subrange) as they're pretty equal in properties
>>>     - NS-Omitting, NS-Preserving, and Private types should be adjacent as well and form a bigger subrange because those share the requirement to be present in delegation responses
>> 
>> Historical convention. Many protocol registries follow this pattern where private types are at the end of a range.
> 
> I understand how you came to this, I just continue to disagree. Practicality should take precedence over historical conventions.

I agree about precedence,  but practicality and historical conventions go hand in hand in this case. Your suggestion may be practical from a developers perspective, where this has to be implemented once, correctly, but the specified order is useful for everyone else: user, operator, etc. In any case, I’d like to keep it this way for now, unless my hand is forced by consensus.


>> 
>> For an NSEC zone, a single NSEC record whose owner name matches the delegation point and whose Next Domain Name is formed by prepending the label \043 to the delegation point satisfies both components of the Name Error proof. It covers both the queried name and the wildcard at the closest encloser, while its Type Bit Maps field indicates the types present at the delegation point. The label \043 sorts after the wildcard label (\042) in canonical ordering.
> Would this even work?
> query: www.deleg-without-ns.example. AAAA DE=0 CO=1
> response: NXDOMAIN, deleg-without-ns.example. IN NSEC \043.deleg-without-ns.example. RRSIG NSEC DELEG
> The queried name is out of the NSEC range...!

Ah, me done f’d up. Thanks Libor. Petr has reminded me several times in the past not to re-iterate existing behaviour from other RFCs, but instead reference it. So here goes the new text for the last line of the preceding paragraph, and I remove the two subsequent paragraphs. Let me know if that works for you:

    Instead, they MUST return a conventional Name Error response with the corresponding DNSSEC denial-of-existence proof as specified in [Section 3.1.3.2 of RFC4035] for NSEC or [Section 7.2.2 of RFC5155] for NSEC3, regardless of whether the Compact Answers OK (CO) flag is set.

Warmly,

Roy