I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up. Do you have a link or resource somewhere so that I can at least get started?
Still unexperienced with letsencrypt, but I know enough that I cannot use the standard way.
I think what they're doing here is running a DNS server on a VM that only answers to requests for specific ACME address prefixes. Then at the actual domain, say example.com, they may ask for cool.example.com but it's a CNAME record that directs to something the DNS server is authority over, say xyz.io or something along those lines.
Therefore ACME's DNS request for checking via DNS validation is validated directly by the tiny DNS server due to the CNAME record directing traffic to it.
I've never done this my self neither, but I think it would be along those lines.
There are a fair few examples out there for hooking acme-dns in as the DNS server with the standard certbot tool. SO search for acme-dns for more info.
Though that isn't actually how I do it (I'm using dehydrated with my own hook script to update a bind9 instance) but probably would be if I started again from scratch.
> I've read about this a few times now, but have been unable to find a good resource on how to set such a VM up.
You first set up a VM and set up your favourite authoritative DNS software on it: popular choices are ISC's BIND and NLnet's NSD. Either will do. Call it (e.g.) ns-dnsauth.mydomain.com, which is Internet accessible only on udp/53 and tcp/53.
You have to then configure that DNS server to serve the domain (e.g.) dnsauth.mydomain.com.
Next you configure the DNS server software to allow dynamic updates. For ISC BIND, you can set up (crypto) keys and use the nsupdate(1) utility:
Point your public/external DNS records to your delegated-auth server by having (say) _acme-challenge.www.mydomain.com be a CNAME to (say) _acme-challenge.www.dnsauth.... LE will follow the CNAME and try to do the verification against the record in dnsauth sub-domain that lives on the ns-dnsauth VM.
Then you have your LE/ACME client(s) run a hook script to publish (and cleanup) the dns-01 TXT challenge records:
The LE client goes to the LE API, gets a verification token/nonce, executes the the hook script to push the TXT record to ns-dnsauth, the LE folks verify the record, the LE client (ideally) cleans up the TXT record, receives the cert for the LE API, puts it in the correct path and restarts your (web) service(s).
Someone actually wrote a limited-functionality DNS server that allows for pushing of records via a REST API for this purpose:
4-6 instances of pdns authoritative for a domain, and pdns recursor running locally for each box. And Cloudflare free tier while revenue can't justify rolling-out Varnish and other locally-deployed capacity/DDoS mitigations.
It may also be a better idea to push DNS updates via configuration management or driven from something like Envoy so there's a history and a single-source-of-truth (SSOT) to point-to rather than multiple people doing manual tinkering, which is a labor-intensive, antiquated approach.
Still unexperienced with letsencrypt, but I know enough that I cannot use the standard way.