mjl-
commented
1 month ago Thanks, this indeed looks interesting. It was mentioned here too: https://github.com/mjl-/mox/issues/126#issuecomment-2228134348
I read through the domainconnect I-D again. Some new notes:
It says the synchronous flow (where you make a one-time DNS change) is more commonly supported than the asynchronous flow (where we could make DNS changes at a later time again). The flow is web-based. Based on that, domainconnect may especially help with the initial setup of mox (at least when mox gets a web-based guided setup), less easily with key rotations.
I'm still a bit suspicious of the central database of service templates, and that we would have to get each dns operator to use ours. Would be good to hear about experiences from developers about that, especially those developing self-hosted software, i.e. not a centralized online service. Signing requests seem recommended (for security), with a public key in the template. But on first look, that seems to assume a service provider that can keep the corresponding private key secret. If that's the case, it wouldn't work for software everyone runs themselves.
I find it surprising that the domainconnect I-D doesn't mention DNS updates (rfc2136), and doesn't mention DNS propagation time considerations, or DNS record rotation considerations (e.g. for DKIM keys, or DANE; it does have a section on merging SPF records, so DNS records for email were at least considered).
Next steps could be to do some prototyping:
- Write a domainconnect template for the records the mox quickstart suggests.
- Find software that can fake being a domainconnect server, for testing the template. Or get it included by a dns operator and get an account with them (seems a bit heavy just for testing).
- Change quickstart to do domainconnect discovery, and print a URL for the user to get the records created.
In other news: I prototyped some code for automated DKIM key rotations, changing DNS records with DNS dynamic updates (rfc2136) and checking/verifying them with AXFR/IXFR, taking propagation times into account (zone negative cache TTL and record TTL). No problems encountered. Still seems like a reasonable approach, at least for my own use case. It will allow for making more kinds of changes from the admin UI/cli (i.e. one click/command to enable acme account binding). The problem of course is that DNS operators don't offer access with those standard protocols. But writing a simple DNS updates/[ia]xfr proxy (that uses an existing Go library (I found multiple candidates) to get/set records through cloud API's) should solve that problem.
mdavids
A thing referred to as 'domain connect' exists:
https://datatracker.ietf.org/doc/draft-kowalik-regext-domainconnect/
What this does it automating the update of DNS records at DNS operators that support this.
Whether or not this is the case, can be discovered by checking for a TXT record
_domainconnect, for example:I don't know how hard it is to implement support for this in Mox, but I could imagine it would be a great feature to have.