Hi Matthijs, Thank you very much for this valuable feedback! More inline
On 6/23/25 16:40, Matthijs Mekking wrote:
I do have an issue with the flow of the document. I have to switch back and forward for the recommendations in section 2 and the rationale in section 3. Personally I think it makes the document hard to access.
Yes, we've thought about this, too. We ended up with this flow because one can imagine that implementers would want the recommendations to be listed in one place, so you can go gloss over them quickly to get an overview of what you'd have to implement (if you wanted) etc. Adding rationale between the recommendation sections would, I fear, scatter them in a way that makes it difficult to grasp quickly what the recommendations entail overall. This is of course from a perspective of a reader of the finished document. While working on it, things may look differently, because one has to keep different parts of the document in mind. So, I'm actually torn either way. The above is just for context. In general, happy to re-arrange; I'll do that when someone brings it up again.
About the recommendations: 2.1. Validity Checks and Safety Measures 2. Parent operators (such as registries) SHOULD reduce a DS record set's TTL to a value between 5–15 minutes when it is updated, and restore the normal TTL value at a later occasion (but not before the old DS RRset's TTL has expired). I understand the logic behind this, but there are also child zone operators that rely on the DS TTL in rollovers. So lowering the TTL is great for quick rollback, but note that this not necessarily speed up the rollover. Not that this is mentioned in the document, but I thought it is worthwhile to point out. Lowering the TTL is fine, but extending obviously is not. Again not that this is mentioned, just saying it out loud.
Thank you, great points; I've added the following: NEW While this approach enables quick rollbacks, timing of the desired DS update process itself is largely governed by the previous DS RRset's TTL, and therefore does not generally benefit from an overall speed- up. Note also that nothing is gained from first lowering the TTL of the old DS RRset: such an additional step would, in fact, require another wait period while resolver caches adjust. For the sake of completeless, there likewise is no point to increasing any DS TTL values beyond their normal value.
2.2. Reporting 3. Notifications to humans SHOULD be done via email. Child DNS operators SHOULD be notified using a report query [RFC9567] to the agent domain as described in ([I-D.ietf-dnsop-generalized-notify], Section 4). The same condition should not be reported unnecessarily frequently to the same recipient. Should "should not" be "SHOULD NOT" here?
Yes, thanks.
About the rationale: 3.1. Validity Checks and Safety Measures There is a TODO in Section 3.1.1. that sounds like it could be a perfect "MAY" recommendation.
That is also my personal view, but I can imagine a whole bouquet of opinions here ;-) I'd like to put this to the WG, either in Madrid or once adopted.
3.2. Reporting A delegation can break even without an update request to the DS record set. This may occur during key rollovers ([RFC6781], Section 4.1) when the Child DNS operator proceeds to the next step early, without verifying that the delegation's DS RRset is in the expected state. This feels a bit hypothetical, perhaps even a bit fearmongering. The key rollover processes described in RFC 6781 clearly say that the child have to wait until the DS RRset has been updated before continuing. So I don't understand why this is used as an example here. You might as well say "this may occur because there was a bug".
Fair point. I'll make a note to gather some data or find a better example (or loosen up the wording etc.). (But also, the fact that rollovers are precisely specified is not a good argument either; if a spec were sufficient, we wouldn't need any acceptance checks at all).
The same condition should not be reported unnecessarily frequently to the same recipient (e.g., no more than twice in a row). For example, when CDS and CDNSKEY records are inconsistent and prevent DS initialization, the registrant may be notified twice. Additional notifications may be sent with some back-off mechanism (in increasing intervals). The history of DS updates should be kept and, together with the currently active configuration, be made accessible to the registrant (or their designated party) through the customer portal available for domain management. This looks like two recommendations that are in the wrong section (although I think it is better to group the rationale and recommendation together per subject).
The first one describes a general property of the reporting mechanism, so where should it go if not into the "Reporting" section? As for the second, it's not really reporting (so, indeed a bad fit), but I'm not sure where else it would fit. I'll rename the section to "Reporting and Transparency".
These two recommendations could use the RFC 2119 uppercase format "SHOULD" instead of the lowercase "should".
Fair. I had intended the analysis section to be non-normative (and only the recommendations themselves use uppercase keywords), but that may not be the right perspective. I've changed as you suggested.
3.4.2. Impact of Manual Updates There are some advises in this section. Is this different than recommendations?
I think this is largely addressed by the fixes from Matt's earlier review. I've removed the "should" and added another sentence to make it even more clear: NEW These conclusions are re-stated in normative language in Section 2.4.
I guess the document could use a thorough pass if there are no recommendations hidden in the rationale part. Or don't split up the recommendations from the rationale.
True! Will go over it again in detail. Diff: https://github.com/desec-io/draft-shetho-dnsop-ds-automation/commit/00b233843905f6a498475cdd5b61b540dc086de3 Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
