Do not put full DNS API credentials on a web server. Delegate the _acme-challenge name to a separate zone with a CNAME, use credentials limited to that zone, or run validation on a separate host and copy the certificate out. Then a hacked web server cannot rewrite your whole DNS.
The risk
DNS-01 proves control by writing a TXT record, so the ACME client needs a way to edit DNS. If that is a general API token on the same machine that serves traffic, an attacker who compromises the web server can change any record: mail, web, verification entries. Let's Encrypt's documentation says this significantly increases the impact of a compromise and recommends narrowly scoped credentials, or validating from a separate server.
Three safer patterns
| Pattern | How it works | Trade-off |
|---|---|---|
| Scoped token | Credential can edit just the needed zone or records | Depends on your DNS provider supporting scopes |
| CNAME delegation | _acme-challenge points to a zone built for validation | One time DNS change, then a small zone to manage |
| Separate validator host | A host with the token gets the certificate and distributes it | More moving parts to deploy |
CNAME delegation, step by step
Let's Encrypt follows DNS standards when it looks up the challenge TXT record, so a CNAME or NS record can hand the answering to another zone.
- Create a small dedicated zone, for example acme.example.net, at a provider with an API.
- In your main zone, create the record that points the challenge name at it:
_acme-challenge.app.example.com. CNAME app.acme.example.net.
- Give your ACME client credentials for the dedicated zone alone.
- Configure the client to write the TXT record there, following your client's documentation for delegated validation.
- Test it against staging. See staging.
The same trick helps when your main provider is slow to update. You can delegate to a quicker server.
Operating it
- Propagation. Providers vary, and some need a wait of up to an hour unless their API reports when a change is live.
- Cleanup. Multiple TXT records for one name are allowed, for example for a wildcard and a non-wildcard certificate together, but remove old ones, since an oversized response is rejected.
- Failure counts. Typos in the CNAME are a frequent cause of failed authorizations. See rate limits.
- Review. Treat the token like any production secret: rotate it, store it in a secret manager, and list who can read it.
Why it matters more soon
Shorter certificate lifetimes and shorter authorization reuse mean validation runs more often, which means credentials get used more often. See ARI and renewal timing.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Can a CNAME really answer a DNS-01 challenge?
Yes. Let's Encrypt follows standard DNS lookups, so CNAME and NS records can delegate the challenge name.
Do I still need DNS-01 for wildcards?
Yes. Wildcard certificates require DNS-01.
Sources
Last reviewed: 19 October 2026.
