@jsha Suggestion to consider that would be much simpler - and much narrower code path change - but would allow for the same level of functionality for hosting providers/private networks/etc as DNS based validation:
Keep using the Simple HTTP based validation, but instead of JUST connecting to IP(domain), add the capability to do a SRV record lookup to determine the ip/hostname to connect to.
i.e.
_letsencrypt-acme-http.<domain>. IN SRV 10 2 80 my-acme-dmz-host.my.same.or.other.domain.
_letsencrypt-acme-https.<domain>. IN SRV 10 2 443 my-acme-dmz-host.my.same.or.other.domain.
That would allow for the scenarios of having a dmz or alternate host to manage the acme enrollment - but still in a mostly automated fashion. Would also allow for the scenarios that many have brought up for cases where they can’t run the ACME software on the actual host - such as when there is a cluster of servers hosting the domain - or for users that have AWS/CloudFront/etc. sitting in front making it more difficult to do the fully automated request.
To me, this would require only very minimal changes to the validation code - to do the additional optional DNS lookup to control what host is connected to for the validation. The rest of the Simple HTTP validation logic could stay exactly the same.
A slight variation of this would be:
_letsencrypt-acme-proxy.<domain>. IN SRV 10 2 80 my-acme-dmz-host.my.same.or.other.domain.
which would be a bit more complicated to implement - since you’d have to be aware of proxy protocol/CONNECT/etc. depending on what URLs you passed through.