Hi Med,
On 10/15/25 07:38, [email protected] wrote:
NEW:
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC7344], and [RFC7477]. Readers may refer to
[RFC6781]
and [RFC8901] for an overview of DNSSEC operational practices.
Done (connect with ", and" instead of repeating "Readers").
[Med] "s/retry schedule/configurable retry schedule" would be sufficient here.
Thanks.
Done.
OLD
To accommodate transient inconsistencies (e.g., replication
delays),
the Parental Agent MAY retry the full process, repeating all
queries.
A schedule with exponential back-off is RECOMMENDED.
NEW
To accommodate transient inconsistencies (e.g., replication
delays),
implementations MAY be configurable to undertake a retry the
full
process, repeating all queries (suggested default: enabled).
A schedule withexponential back-off is RECOMMENDED.
[Med] I like this. Thanks.
Done.
# Not an absolute requirement
OLD:
Existing requirements for ensuring integrity remain in
effect. In
particular, DNSSEC signatures MUST be requested and
validated for all
queries unless otherwise noted.
NEW:
Existing requirements for ensuring integrity remain in
effect. In
particular, DNSSEC signatures SHOULD be requested and
validated for all
queries unless otherwise noted.
No, it is an absolute requirement for the queries talked about in
this document, which are:
- CSYNC: RFC 7477 Section 2 (last paragraph) prescribes validation
- CDS/CDNSKEY:
* for updates: RFC 7344 Section 6.2 says "MUST check the
publication rules from Section 4.1", which says that these RRsets
"MUST be signed with a key that is represented in both the current
DNSKEY and DS RRsets", so this is a validation requirement
* for bootstrapping: RFC 9615 Section 4.2 requires validation
The above quote does not affect any other queries (the first
paragraph of that containing section says that these are
"requirements that apply equally to CDS/CDNSKEY and CSYNC", not to
anything else).
[Med] .. but we say "unless otherwise noted" in the text, which is an exception.
Yes, and in fact it is otherwise noted in the last paragraph of Section 3.1,
which says:
During initial DS provisioning (DNSSEC bootstrapping), conventional
DNSSEC validation for CDS/CDNSKEY responses is not (yet) available;
in this case, authenticated bootstrapping ([RFC9615]) should be used.
As a reminder, 2119 says:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
There are no SHOULD-style valid reasons for implementations to deviate from the
validation requirement.
I believe the issue is that you're reading
DNSSEC signatures <MUST be requested and validated for all
queries> unless otherwise noted
while what's meant is
DNSSEC signatures MUST be <requested and validated for all
queries unless otherwise noted>
So the "unless" is not an exception from the MUST; rather, it qualifies what
exactly implementations MUST do.
Making up another example, this is comparable to "clients MUST use TLS 1.3 unless not supported by the
server", where the "unless" is not a SHOULD-style exception. "clients SHOULD use TLS
1.3" means something else.
I recognize however that the wording apparently is unclear. I'm not sure how to
clarify; do you have a suggestion?
FYI, the diff page linked in my previous message also contains the changes
confirmed in this message.
Thanks,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
