ACME DNS validation: automate the challenge without exposing the service

ACME DNS validation proves control of a domain using DNS records rather than a request to the protected web server. In the DNS-01 challenge, the client publishes a challenge-specific TXT value under an _acme-challenge name, and the certificate authority checks it.

That makes DNS-01 useful for wildcard certificates and services whose web ports are not publicly reachable. It does not install the issued certificate, remove the need to protect private keys, or make domain validation permanent.

Choose DNS-01 for the validation problem it solves

Consider the service and its deployment path. An internet-facing web server may work well with a standard HTTP challenge. A private gateway with a publicly registered domain, or a wildcard certificate, may need a DNS-based approach.

Let's Encrypt's challenge documentation explains that DNS-01 supports wildcard issuance and can validate names whose web servers are not exposed publicly. HTTP-01 uses port 80 and cannot issue wildcard certificates. The appropriate method depends on your CA and client capabilities.

Private reachability does not make a private-only or invented domain eligible for a publicly trusted certificate. Confirm that the requested names and the public DNS validation path are suitable for the CA you use. Internal service certificates can also come from a private PKI, which has a different trust model.

Understand the TXT record and the renewal cycle

The challenge value belongs to a particular authorization attempt. A TXT record copied into DNS during the first issuance is not a general-purpose renewal credential.

Your automation needs to obtain the challenge, publish the required value, wait until the value is available to the authority, complete validation, and clean up appropriately. Existing authorizations may be reusable within the authority's permitted window, but the workflow must be able to perform fresh validation when required.

Treat the DNS owner as an operational dependency. If only one person can edit a zone, manual DNS validation has moved the renewal ticket rather than removed it. Document the access path before the certificate enters its renewal window.

Use delegation carefully

Some workflows delegate the challenge name to a separate validation zone. Let's Encrypt documents CNAME and NS delegation for DNS-01. That can let a dedicated system answer validation requests without giving every application server permission to edit the main zone.

Check that your ACME client and validation service actually support the delegation pattern. The fact that an authority follows DNS delegation does not mean every client will discover and update the delegated zone automatically.

For an illustrative CNAME delegation, the DNS record might look like this:

_acme-challenge.vpn.example.com. CNAME validation-id.validation.example.net.

This is a fictional example, not a Certonomy setup value. Use the exact target generated by your validation service. A delegation can remain in place across renewals while the service publishes fresh challenge values at the delegated target. That is reusable configuration, not permanent proof of domain control.

Scope access to the validation task

Decide which system may change the challenge records and what else its credentials permit. Prefer a narrowly scoped identity or dedicated validation zone where the provider supports it. Avoid giving a web server broad control over unrelated customer DNS records just to renew one certificate.

Keep tokens in your credential system and reference them from automation. Record how to rotate and revoke them. During customer offboarding, remove the delegated authorization path as well as the device access, following your agreed ownership process.

The delegation itself deserves review. A persistent record gives the validation target an ongoing role in future issuance for that challenge name. Know who controls the destination and how you would remove it if access changed.

Troubleshoot the DNS answer the authority sees

When validation fails, check the exact requested name and challenge value. Inspect authoritative DNS answers, not only the DNS provider's editing screen or a cached answer on your laptop.

Common investigation points include the wrong zone, a duplicated domain suffix in a record editor, an outdated delegation target, propagation delays, or a client that updated the original name rather than the delegated destination. If the CA reports another policy error, follow that error instead of repeatedly replacing the TXT value.

Record the failed stage and preserve the error. Avoid repeated production issuance attempts while guessing. Use the authority's test environment where available, with a separate test deployment that cannot replace a working production certificate with an untrusted test certificate.

Connect validation to deployment and verification

Successful DNS validation permits issuance. The issued certificate still has to reach the device holding the matching private key, be assigned to the correct listener, and pass a live check. The automatic deployment guide covers those later stages.

Certonomy's published workflow uses a CNAME setup and an on-site agent. Read “prove the domain once” as the initial delegation setup; fresh CA validation is still part of certificate issuance when required. The agent workflow keeps private keys on the customer site and includes deployment verification. Review the launch scope and founding access for your fleet.