Hi Med,
Thank you very much for your detailed feedback.
On 10/1/25 17:50, [email protected] wrote:
Both the issue and proposed approach are well explained. I only have few minor
comments. I sent you a PR with some nits:
https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/5/files
<https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/5/files>.
Thanks, merged.
# Make idnits happy
Please add the following to the abstract:
NEW:
This document updates RFC 7344 and RFC 7477.
Done (via your PR).
# Background reading
CURRENT:
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC6781], [RFC7344], [RFC7477], and [RFC8901].
(1) This smells like a normative dependency on all these specs, but there
RFC6781 and RFC8901 are provided as informative.
To fully understand the document (including its justifying arguments),
familiarity with these last two documents is needed, but they are not
normatively relevant for the specification. So I think the current wording is
correct.
(2) Any reason why RFC 9364 is not cited here rather than pointing to these
individual RFCs?
Yes, because one only needs to be familiar with the aspects of DNSSEC mentioned
above, but for example not with RFC 7646 or RFC 9276, which both are listed in
9364. That said, I don't feel strongly at all and will be happy to change it if
you prefer.
# Restating an existing behavior, not defining a new one
In Section 1:
OLD:
At the same
time, applying an automated delegation update "MUST NOT break the
current delegation" ([RFC7344], Section 4.1), i.e., it MUST NOT
hamper availability or validatability of the Child's resolution.
NEW:
At the same
time, applying an automated delegation update "MUST NOT break the
current delegation" ([RFC7344], Section 4.1), i.e., it must not
hamper availability or validatability of the Child's resolution.
Also, same in Section 3.1
OLD:
In other words, CDS/CDNSKEY records at the Child zone apex MUST be
fetched directly from each (reachable) authoritative server as
determined by the delegation's NS record set.
NEW:
In other words, CDS/CDNSKEY records at the Child zone apex must be
fetched directly from each (reachable) authoritative server as
determined by the delegation's NS record set.
Agree, and also done (via your PR).
Reading this I realize that the case of CDS/CDNSKEY "delete" signals (RFC 8078 Section 6)
is covered ("Specifically, it MUST NOT delete" in Section 3), but I think it should also
be covered explicitly in Section 3.1. So I've added:
OLD
Parent, and ensure that each key referenced in any of the received
answers is also referenced in all other received responses.
NEW
Parent, and ensure that each key referenced in any of the received
answers is also referenced in all other received responses, or that
responses consistently indicate a request for removal of the entire
DS RRset ([RFC8078], Section 6).
... and in the next paragraph (which you quoted above), I changed at the end:
OLD
considered inconsistent.
NEW
considered inconsistent. Similarly, the state MUST be considered
inconsistent if there is a CDS or CDNSKEY response that indicates a
removal request for the DS RRset whereas another response indicates
no change (NODATA) or a DS update.
This is a no-op clarification, so I'll assume it is fine unless I hear
otherwise.
# Update to RFC 7344
The spec extends the acceptance rule list, but does not change any other part
of 7344. I suggest to make that explicit:
OLD:
This list is extended with the consistency requirements defined in
this document.
NEW:
This list is extended with the consistency requirements defined in
this document. This document does not modify any other part of [RFC7344].
Done (via your PR).
# Configuration knobs/Operational Considerations (Section 3)
CURRENT:
A retry schedule with exponential
back-off is RECOMMENDED (such as after 5, 10, 20, 40, ... minutes).
In your PR, you changed this to "e.g., after 5, 10, 20, or 40 minutes". I accepted the
"e.g.,", but disagree with the "or", as this is an example of a sequence of retries
retries with exponential back-off, and not a list of alternatives of intervals.
I guess this should be a configurable parameter. Can say so. This would be
aligned with the similar provisions in the Operational Considerations of
RFC7477.
All kinds of things can be configurable, and we usually don't say that, so I'd rather not say it
here. However, if you prefer, would it would for your if we added "(configurable)" before
"retry schedule"?
Also,
CURRENT:
To accommodate transient inconsistencies (e.g. replication delays),
the Parental Agent MAY retry the full process
whether this is retried or not should be controlled using a knob. Indicating
whether the retry is enabled or disabled by default may be worth to mention.
I feel the same here about configuration statements as above. Also, how can it
be that it should be done a certain way when it is MAY?
However, if you really want this, how about the following:
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.
Idem for this one:
CURRENT:
A schedule with exponential back-off is RECOMMENDED.
I guess the schedule should be a configurable parameter.
True, although I don't think we need to repeat that here if we say it above
when we first talk about exponential back-off. Do you think?
# 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).
# References
Please use the exact titles of these references:
OLD
[LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker,
G. M., Savage, S., Claffy, K., and ACM, "Unresolved
Issues", Proceedings of the ACM Internet Measurement
Conference, DOI 10.1145/3419394.3423623, 27 October 2020,
<http://dx.doi.org/10.1145/3419394.3423623>.
ACM, "Risky BIZness", Proceedings of the 21st ACM Internet
Measurement Conference, DOI 10.1145/3487552.3487816, 2
November 2021,
<http://dx.doi.org/10.1145/3487552.3487816>.
NEW:
[LAME1] Akiwate, G., Jonker, M., Sommese, R., Foster, I., Voelker,
G. M., Savage, S., Claffy, K., and ACM, "Unresolved Issues:
Prevalence, Persistence, and Perils of Lame Delegations", Proceedings of the ACM
Internet Measurement
Conference, DOI 10.1145/3419394.3423623, 27 October 2020,
<http://dx.doi.org/10.1145/3419394.3423623>.
[LAME2] Akiwate, G., Savage, S., Voelker, G. M., Claffy, K C, and
ACM, "Risky BIZness: risks derived from registrar name
management", Proceedings of the 21st ACM Internet
Measurement Conference, DOI 10.1145/3487552.3487816, 2
November 2021,
<http://dx.doi.org/10.1145/3487552.3487816>.
Done.
I'll await your response before I submit a new revision. Meanwhile, you can look at
the combined above changes using this diff:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-dnsop-cds-consistency-08&url_2=https://raw.githubusercontent.com/peterthomassen/draft-ietf-dnsop-cds-consistency/refs/heads/main/draft-ietf-dnsop-cds-consistency-09.txt
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
