> On 2 Nov 2026, at 09:11, Libor Peltan <[email protected]> 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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
