Automated deployment pipeline Use-Case

[pawel-kow]

Section 3.2: Use Cases out of scope says:

While Domain Connect offers significant advantages in automating DNS
configuration, it's important to recognize scenarios where it might
not be the ideal solution:

*  *Automation or CI/CD Pipelines:* Domain Connect is primarily
   designed for user-driven DNS configuration, where an end user
   grants consent and applies changes.  Automating this process
   within CI/CD pipelines or other automated workflows can be
   challenging, as it requires obtaining and securely storing OAuth
   tokens beforehand.  However, if authorisation tokens are pre-
   obtained from a user-driven setup process, Domain Connect can be
   also integrated into automation workflows.

I would think that an automated deployment pipeline would be the common case and that the protocol should be designed for that case, where manual "user-driven" configuration is a necessary but hopefully uncommon case. This has immediate security implications, in that it would be appropriate to support some authentication protocol like using PKIX certificates for TLS authentication of people or processes rather than using OAuth (which is aimed at authenticating human users). I couldn't tell how difficult it would be to be agile with respect to security mechanisms or how difficult it would be to work with OAuth.

[PK] Complexity of such considerations was so far the main issue to put
it out of scope or park at least. Automated DNS configuration by a
technical system is usually addressing a different problem definition
(a.k.a. standardised DNS configuration API), where likely the securities
and trust model of domain connect are oversized or even not necessary at
all. Anyway I would be happy to see discussion on this on the mailing
list in case anyone considers this problem worth solving.