If there is concern and/or confusion on deploying DS automation, a
document that makes recommendations and clarifications in order to ease
the deployment path sounds like a good idea.
I started reading this draft and most of the recommendations make sense
to me.
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.
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.
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?
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.
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".
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). These two recommendations could use the RFC 2119
uppercase format "SHOULD" instead of the lowercase "should".
3.4.2. Impact of Manual Updates
There are some advises in this section. Is this different than
recommendations?
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.
Best regards,
Matthijs
On 30-04-2025 20:37, Peter Thomassen wrote:
Dear DNSOP,
There are a number of loose ends regarding CDS/CDNSKEY automation, and
various implementers have made different choices. Examples are questions
around validity checks, timing, error reporting, locks, etc.
Some gTLD registries have undertaken to deploy CDS automation [1], but
ICANN has pointed out that these issues will first have to be resolved
before DS automation will be allowed functionality in the gTLD space.
This seems like a reasonable position for maximizing interoperability
and minimizing surprise.
The insight about these concerns and the resulting "dependency"
crystalized in consultations around the creation of SAC126 [2]. As a
result, the report lists them; this draft now picks up the open issues
and attempts to address them.
Looking forward to your feedback.
Best,
Peter
[1]:
https://www.icann-hamster.nl/ham/soac/ssac/dnssec/icann76/4.5%20Bauland%20-%20CDNSKEY%20Support%20in%20TANGO%20Registry%20Services.pdf
[2]:
https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-126-16-08-2024-en.pdf
-------- Forwarded Message --------
Subject: New Version Notification for
draft-shetho-dnsop-ds-automation-00.txt
Date: Wed, 30 Apr 2025 11:16:16 -0700
From: [email protected]
To: Peter Thomassen <[email protected]>, Steve Sheng <[email protected]>
A new version of Internet-Draft draft-shetho-dnsop-ds-automation-00.txt has
been successfully submitted by Peter Thomassen and posted to the
IETF repository.
Name: draft-shetho-dnsop-ds-automation
Revision: 00
Title: Best Practice Recommendations for DS Automation
Date: 2025-04-30
Group: Individual Submission
Pages: 21
URL:
https://www.ietf.org/archive/id/draft-shetho-dnsop-ds-automation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-shetho-dnsop-ds-automation/
HTML:
https://www.ietf.org/archive/id/draft-shetho-dnsop-ds-automation-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-shetho-dnsop-ds-automation
Abstract:
Enabling support for automatic acceptance of DS parameters from the
Child DNS operator (via RFCs 7344, 8078, 9615) requires the parent
operator, often a registry or registrar, to make a number of
technical decisions. This document describes recommendations for new
deployments of such DS automation.
The IETF Secretariat
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
