Early Review of draft-kowalik-domainconnect-02
review-kowalik-domainconnect-02-secdir-early-kaufman-2025-12-30-00

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"