Hi Peter,
Thanks for your reply and changes to the document. See responses inline.
On 30-06-2025 17:17, Peter Thomassen wrote:
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.
I am an implementer ;)
I would like to know the rationale for a given recommendation.
Understanding why usually makes things easier to do.
If you want the recommendations in one place you could also do that by
summarizing them in a separate section at the end.
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.
Thanks.
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".
I thought one of your goals was to list all recommendations in one
place? These are outside the "Overview of Recommendations" section.
So at least the flow of the document (listing recommendations together
vs grouping rationale with recommendation) is inconsistent.
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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
