I saw this go by in April and thought it looked like a good idea, but other things distracted me and I forgot to come back to it. Thanks to Peter for the reminder on the OARC chat server yesterday.
I'm generally in favour of any work that moves DS automation forward. It seems like the registrars are not going to find a financial incentive to do CDS/CDNSKEY scanning, and so I agree it's time to try to overcome the hurdles at the TLD level. This looks like a good start. Peter was asking in chat if people thought this should have agenda time in Madrid. I won't be there so my opinion on that probably doesn't matter, but I would like to see the WG doing some kind of work along these lines. On first read I think I agree with most of the recommendations in this document. I need to spend more time with this, but a few comments have already come to mind. In general: 1. Do we have enough operational experience for this to be a Best Practices document? The reason I ask is that I think the problem we're trying to solve here is that not enough organizations are doing automation. There are also recommendations in here that I have never heard of anyone doing yet (for example, Parent->Child notification of DS update success or failure). Should we instead be talking about "operational considerations for..." or something along those lines? 2. There are recommendations here that imply lots of additional state in registry software (as opposed to DNS software). This isn't a bad thing, but we should make sure that this gets review by registry implementers, in whatever WG makes sense, to make sure that we're not recommending practices that will inhibit implementation. And more specifically: 2.1 recommendation 2 could be clearer. There are three states of DS record mentioned, so the use of "the old DS" seems open to misinterpretation. 2.4: - recommendation 1: I don't understand what it means for there to be a registry and a registrar involve, but to then somehow be outside the RRR model. Is the parenthetical clause here actually "when EPP is not used"? I see a few other places in the document where I think probably you mean "when EPP is in use" but instead say "when the RRR model is used". - recommendation 3: Is there a time period implied here, or should the registry suspend automation forever? Or only until a DS set is manually re-added? I don't think recommendation 4 completely answers that question. - recommendation 6: This recommendation might be controversial. It could be argued that if the registrar doesn't support DNSSEC at all, then there's extra justification for the registry to do automatic updates. Perhaps I'm missing it, but I don't see any discussion of the arguments for or against later in the document, justifying this recommendation. 3.4: - The phrasing of the first two bullet points imply the wrong actor if they're talking about DNSSEC automation. The registry and registrar do not receive updates from a child operator... they poll the child operator to see if updates are available. Generalized notifications will eventually (if standardized and adopted) blur this line a bit, but certainly today there is no action a child operator can take to push data upstream. - The third bullet point could reference the earlier recommendations more cleanly if it included the phrase "manual update" somewhere. 3.4.2: I find the structure of paragraph 2 difficult to understand. I think what's throwing me off is that it starts by talking about the practice of "suspending DS automation after a manual update", ends by saying it is "not advised to follow this practice," but argues in the middle that resuming automation carries the risk of surprise or breakage. The fact that the arguments in the middle are in favour of suspending automation and sound like the opinion of the document, rather than an opinion being repeated and critiqued, makes the "it is therefore advised.." conclusion very confusing. Later text clarifies the position being taken, but I think a different structure to the whole section would help a lot. Similarly, I think there should be a clearer separation when you switch to talking about the special case for manual updates that disable DNSSEC. That is separate advice, and could use it own paragraph to make that clear. A nit: - there's a formatting error in 2.1, recommendation 1b. -------- 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]
