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?
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 suggest to arrange the subranges in the order of (ns-omitting,
ns-preserving, private, on-demand).
If there is any more argument, I would add that the "on-demand" subrange
is in fact so different in behavior, that it doesn't belong among the
former three, and as a result, the "private" subrange is kind-of 'at the
end' of the sane range of (ns-omitting, ns-preserving, private) ... :)
3) It should be made clear that the DE bit not only signals (commits
to) Delegation-Extension-awareness, but also DELEG-awareness.
Ack .... I’ve added the last sentence: ... I’ve also added to 5.1: .....
Ack
4) Compact Denial of Existence: §4.1.1 seems not precise enough.
First, it doesn't clearly say that the considerations are regarding
queries _below_ the non-NS delegation point. Second, it doesn't say
how the non-NXNAME NXDOMAIN answer should look like (especially, how
the "next name" field in the NSEC is crafted).
Good points. Regarding your first points, I’ve updated the text in
4.1.1 to:
This document updates Compact Denial of Existence (CDOE)
[RFC9824]. For queries with DE=0 and a QNAME below a delegation point
containing an NS-Omitting Delegation Type RRset but no NS RRset,
authoritative servers implementing Compact Denial of Existence (CDOE)
[RFC9824] MUST NOT use the CDOE method when the DE flag is clear.
Instead, they MUST return a conventional negative response with the
corresponding DNSSEC denial-of-existence proof as specified in
[RFC4035] or [RFC5155], regardless of whether the Compact Answers OK
(CO) flag is set.
Nice.
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...!
6) Queries for type ANY (4.4) is underspecified. Either improve, or
remove this section whatsoever.
I’ve improved it,
Ack
X) In general, I lack enough considerations about DE-rrtypes without
DNSSEC. Yes, their security properties are obviously weak, but
they're not forbidden or unuseful. Although not all, most of the
paragraphs assume DNSSEC.
Okay. What more is there to say about DE-rrtypes without DNSSEC?
Sorry, this way my incorrect perception.
Y) Question. Assume a hybrid delegation with both legacy NS and
NS-Omitting DELEG. Within the given Threat Model, should we consider
the attack surface where for a legacy resolver, the attacker
_injects_ a malicious DE bit into the resolver's queries, so that the
resolver obtains cachable de-facto NXDOMAIN proofs of stuff below the
delegation? I guess the defence is the presence of NSEC which
uncovers the existence of NS, but this is not mentioned in the doc.
It isn’t mentioned here, as this is covered by RFC6840 section 4.1,
but I’m happy to add the following after the first paragraph of
Section 8.4:
An on-path attacker may set the DE flag in queries sent by a
non-Delegation-Extension-aware resolver, causing an authoritative
server to return Delegation Type RRsets instead of an NS RRset. At a
delegation point containing both NS and NS-Omitting Delegation Type
RRsets, the NSEC or NSEC3 record matching the delegation point
indicates the presence of the NS RRset. As specified in [@!RFC6840]
Section 4.1, a validating resolver cannot use such an ancestor
delegation proof to establish nonexistence below the delegation point.
Consequently, injecting the DE flag cannot cause a
non-Delegation-Extension-aware validating resolver to accept an
authenticated denial of existence for names below the delegation.
Pretty!
Thanks Libor,
Warmly,
Roy
Thanks,
Libor
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
