Hi Roy,
On 02. 11. 26 14:05, Roy Arends wrote:
On 2 Nov 2026, at 09:11, Libor Peltan <[email protected]> wrote:
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.
OK, let me know once this is resolved somehow for draft-delext.
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.
This seems to be resolved in -13 by defining the "private" subsubrange
to all the three behavioral-subranges. OK for me.
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.
I'd argue that referring to RFC 4035 §3.1.3.2 is nether precise nor
helpful anyway. The CDoE signer is not going to "find" but "construct"
the NSEC RR and there is still no guidance how its Next Domain Name
field shall be constructed. In fact, I myself have hard time figuring
this out.
Situation:
query: www.deleg-without-ns.example. AAAA DE=0 CO=1
response: NXDOMAIN, deleg-without-ns.example. IN NSEC <next_name> RRSIG
NSEC DELEG
What shall the <next_name> be?
a) \043.deleg-without-ns.example. (as specified in delext-12) obviously
wrong. The NSEC doesn't cover the QNAME.
b) next-existing-name.example. (probably best interpretation of the
reference to RFC 4035) obviously non-practical. Facilitates zone
enumeration/iteration, defeating the mainstay of CDoE itself.
c) \000.www.deleg-without-ns.example. (straightforward application of
"black lies" concept, which is core to CDoE, RFC 9824 §3.1) doesn't hold
to the invariant that "there is nothing below DELEG", defeating the
whole new delext requirement.
d) deleg-without-ns\000.example. (the label itself is "incremented by
one") probably the way to go: immediate successor of the QNAME which is
not below the DELEG. But how to describe this in a sane way? Probably
somehow refer to RFC 9824 §3.4 ?
(Additional note on RFC 9824: the construction of lexicographic
successor in §3.1 and §3.4 is not entirely correct. For example, if
QNAME is aleady of maximal name length (or one below), there is no way
of prepending the \000. label, and the first label has to be incremented
instead like in §3.4. Moreover, if the first label is of maximal label
length, it can't be incremented by appending the \000, but by
incrementing its last octet. Moreover, if it consists only of "\255"
octets, it can't be incremented at all and has to be stripped... And so
on. But I guess we shouldn't dive into this here and now.)
Warmly,
Roy
_______________________________________________
Libor
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
