The DNS-01 Challenge: How Wildcard Certificates Actually Get Issued

Getting a TLS certificate issued automatically, through Let's Encrypt or any other ACME-based CA, requires proving you actually control the domain first. There are a few accepted ways to prove that. For a wildcard certificate, there's exactly one, and it runs entirely through DNS.

The three ways ACME validates domain control

The ACME protocol defines several challenge types, but two cover almost every real setup. HTTP-01 asks you to serve a specific file at a specific path on the domain being validated, proof that whoever controls the web server also controls the domain. TLS-ALPN-01 does something similar over a TLS handshake instead of plain HTTP, useful when port 80 isn't available. DNS-01 asks you to publish a specific TXT record instead, proof that whoever controls the DNS zone controls the domain.

For an ordinary single hostname, any of the three work, and HTTP-01 is the default for most tooling since it needs no DNS access at all, just a web server. DNS-01 is the odd one out operationally, since it needs API access to your DNS provider rather than just a running web server.

Why wildcards specifically require DNS-01

HTTP-01 and TLS-ALPN-01 both validate one specific, connectable hostname: they need somewhere to serve a file or respond to a handshake. A wildcard doesn't correspond to any single hostname at all, it's a pattern covering every subdomain at one level, so there's nothing concrete to serve a file from or answer a TLS challenge at. DNS-01 sidesteps that entirely by validating control of the zone itself rather than any one host within it, which is exactly the scope a wildcard needs proof of.

What the challenge actually looks like

Your ACME client requests a challenge, generates a value derived from a token the CA gives it, and publishes that value as a TXT record:

_acme-challenge.example.com.    TXT    "gfj9Xq...Rg85nM"

The CA then queries that name and confirms the value matches what it expects. If it does, the CA considers the domain validated and issues the certificate.

Why it's always the base domain, even for a wildcard

The _acme-challenge record always sits at the domain itself, _acme-challenge.example.com, regardless of which specific hostname or wildcard is actually being validated. Requesting a certificate for *.example.com still means publishing the challenge at _acme-challenge.example.com, not at some wildcard-specific location. This is consistent with the challenge validating the zone as a whole rather than any individual name within it.

The propagation problem

The CA has to actually see the TXT record before it'll validate, which means the record needs to have propagated to whichever resolvers the CA checks against. This is the same underlying mechanic covered in why DNS propagation takes so long: a record that was just created can take longer than expected to become visible everywhere, and a validation attempt that runs too soon after publishing the TXT record can fail simply because it hasn't propagated yet, not because anything is actually wrong. Most ACME clients build in a wait before checking, but a validation failure on a fresh DNS-01 attempt is worth retrying before assuming something's broken.

Delegating the challenge to a separate zone

Automating DNS-01 means giving your ACME client credentials to modify DNS, and doing that on every server that renews a certificate means every one of those servers holds API access to your primary DNS zone. A common mitigation is delegating just the _acme-challenge subdomain elsewhere, via a CNAME pointing it at a separate, dedicated validation zone, or an NS delegation handing off that one subdomain entirely. The CA follows the delegation automatically since it's just resolving a name through DNS like anything else, and the credentials your automation actually needs are scoped to that narrow validation zone instead of your entire domain's real DNS records.

How this connects to CAA

Publishing a valid DNS-01 challenge doesn't bypass CAA records. A CA is still required to check CAA before issuing, regardless of which challenge type validated the request. If your CAA record doesn't authorize the CA you're requesting a certificate from, a successfully completed DNS-01 challenge still won't result in an issued certificate.

Checking for a leftover challenge record

_acme-challenge TXT records are meant to be transient, created for a validation attempt and often left in place or overwritten on the next renewal rather than cleaned up. A stale one from a decommissioned automation tool is generally harmless, since it only matters during an actual validation request, but it's easy to accumulate a few over time:

dig TXT _acme-challenge.example.com

How DNS monitoring fits in

_acme-challenge records are one of the few cases where frequent change is completely normal rather than a signal of anything wrong, since a new value gets published on every renewal cycle. That's worth knowing before setting expectations for what a monitoring alert on this specific record means: OneDollarDNS will flag a change here like any other TXT record, but a value that's different from last time is exactly what a healthy, automated renewal looks like, not evidence of a problem. What's actually worth watching is whether the record exists and updates on the cadence your renewal process expects, not the specific value itself.