How do you securely handle ACME DNS-01 certificate validation?

Delegate only the _acme-challenge name to a separate DNS zone. The ACME clients can then use an API key or update key that is limited to creating TXT records in that zone, without getting access to the rest of your DNS. With BIND, this can be enforced using a dedicated key and update policy.

For a central application serving many customer subdomains, a reverse proxy or dedicated certificate service can obtain and renew the certificate, then make it available to the application through a controlled deployment process. If you use wildcard certificates, avoid distributing the private key across multiple systems; a leak means replacing the wildcard certificate everywhere. Per-service certificates are preferable when the architecture allows it.

Another option is to use an ACME client with a narrowly scoped DNS provider credential. For example, the client can authenticate to Azure DNS, Cloudflare, or Route 53 through an application identity that can modify only the required zone. This keeps the shared-hosting machines from having broad DNS privileges.

A verification-domain setup works well: point _acme-challenge.example.com to something like challenge.validation-domain.com with a CNAME or NS delegation. The ACME client only needs permission to create records in the separate validation zone. Cloud DNS providers and tools such as Posh-ACME, Certbot plugins, or platform-specific clients can automate this.