Reviewer: Charlie Kaufman
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies a protocol by which operators who to update DNS entries maintained by a third party DNS provider can request such changes in a standardized way. While the document doesn't say, I infer that today third party DNS providers all have their own mechanisms for accepting such requests and large operators who must work with many third parties have to learn how to deal with each one. If so, a protocol of this sort seems woefully overdue and would be welcomed by the community. DNS providers would face pressure to support the protocol.

I'm concerned that this standards track RFC is coming in as an individual contribution. I would expect there to be widespread interest and that the authors would find or start an appropriate working group.

This is not my area, so many of my comments may be ill-informed, but I will offer them anyway for whatever they are worth.

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.

I'm suspicious of the synchronous flow. Is it common for DNS providers to be able to make updates in real time? I would expect - especially in cases where DNSsec is supported - that it might be better to be able to accept a request (so the sender is guaranteed it will happen eventually, possibly with an estimate or commitment as to how long it will take) rather than delaying a response until the update is completed, especially given that if there is a crash while waiting the requestor doesn't know whether he has to resubmit it.

Section 5.2.1 is very confusing. It is trying to express what trust various components are placing on others (I think). But it comes off as either being obvious or expressing something so subtle that it goes over my head.

I really like the idea (in Section 7) of posting configuration information in DNS, though it is sufficiently rare that I wonder whether the DNS folk will object. And posting information about how the information should be displayed on the user's screen seems over the top.

Nits:

Section 3.2 vs. Section 8.2.1.2: authorization or authorisation -- pick a spelling and stick with it.

Section 4: "mean of communication" -> "means of communication"

Section 7: "suceeds" -> "succeeds"

Section 8.4.1: "asyncronous" -> "asynchronous"

Section 8.4.3: "primarly" -> "primarily"

Section 8.4.3: "temporarilly_unavailable" -> "temporarily_unavailable"

Section 10.3: "specifed" -> "specified"

Section 10.4: "desireable" -> "desirable"