Hi Matt,
On 6/21/25 19:33, Matthew Pounsett wrote:
I'm generally in favour of any work that moves DS automation forward. [...]
On first read I think I agree with most of the recommendations in this document.
Thank you for taking a look, and for supporting the effort!
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.
Definitely. I'm planning to circulate this very broadly, with presentations
given not only at IETF and DNS OARC, but also at the relevant ICANN
constituencies (e.g., GNSO, which represent the gTLD registries and
registrars). Also, ICANN Org is in the loop, and the plan is indeed that *no*
actor will experience any surprises when this is published, with real consensus
on how it's best done (and why).
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.
I'm not sure which three states you mean, but I've changed the wording a
little; let me know if you meant something else:
NEW
2. Parent operators (such as registries) SHOULD reduce a DS record
set's TTL to a value between 5–15 minutes when the set of records
is changed, and restore the normal TTL value at a later occasion
(but not before the previous DS RRset's TTL has expired).
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".
Ah, good catch. ICANN's contractual registrar agreement already requires
registrars to offer a way to provision DS records, so I meant to focus on the
ones that are not under such a contract (in particular, certain ccTLD
registrars). But indeed, the wording chosen does not say that. :-)
Instead of complicating the wording, I've removed the parenthetical clause, so it now
says "Registries and registrars". This means that the recommendation is no-op
for ICANN-accredited registrars, but I guess that does no harm.
- 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.
Permanently; the point is that when the registrant has manually removed all DS
records, they shouldn't be put back automatically (also not next year).
In my view, this is what a "suspend" without qualification says -- but you're
probably better at English :-) Do you have a suggestion?
- 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.
Section 3.4.1 explains it:
[...] when the registrar is known to not support DNSSEC (or lack
a manual interface), it seems adequate for registries to not perform
automated DS maintenance, in order to prevent situations in which a
misconfigured delegation cannot be manually recovered by the
registrant.
In my view, the registrant *must* have the last manual word, and if it's known
that no such manual word is possible, then automation should not be happening.
1. Do you agree?
2. If so, how else could this be handled (if not by what recommendation 6 says)?
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.
Good point, changed "receive" to "retrieve".
- The third bullet point could reference the earlier recommendations more cleanly if it
included the phrase "manual update" somewhere.
Changed as follows:
NEW
* Registrars or (less commonly) registries can obtain the
information from the registrant performing a "manual update", such
as via webform submission, and relay it to the registry.
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.
Thanks for your feedback; I see your point. I've made minor changes to all
paragraphs in 3.4.2 to improve clarity. I'm not copying it here due to its
length, but you can see it in
commit
https://github.com/desec-io/draft-shetho-dnsop-ds-automation/commit/7f5a83b4b0c4b649300b18a1cf55d919bcc27290
the editor's copy:
https://desec-io.github.io/draft-shetho-dnsop-ds-automation/draft-shetho-dnsop-ds-automation.html#name-impact-of-manual-updates-wh
A nit:
- there's a formatting error in 2.1, recommendation 1b.
Happy to fix, but which formatting error do you mean?
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
