ACME DNS-01 challenge propagation delays

DNS-01 renewal failed because Let's Encrypt could not read the correct TXT at _acme-challenge—fix authoritative DNS, not the CA.

When this happens

cert-manager or certbot logs show timeout waiting for DNS propagation after you added a TXT record. Manual dig from your laptop shows the token, yet issuance still fails an hour later. Secondary symptoms include cert-manager Challenge objects flipping between valid and invalid while the TXT in your SaaS DNS console never changed—support blames the CA even though authoritative NS still serves the previous token.

You moved DNS to a new provider but left _acme-challenge CNAMEs pointing at the old zone. Wildcard renewals fail while single-host HTTP certs still work. Partial zone imports from legacy registrars sometimes omit _acme-challenge glue until the second manual save in the panel.

First response

DNS-01 ACME failures from slow or wrong TXT propagation—verify _acme-challenge from multiple resolvers before reissuing.

Searches for acme dns challenge failed usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For ACME DNS-01 challenge propagation delays, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

DNS-01 incidents drag on because every resolver caches TXT answers differently and the CA's vantage may not match your office DNS. Before you rotate API tokens or switch CAs, prove the _acme-challenge label resolves identically from Google Public DNS, the issuer's stub resolver, and the recursive server your automation uses. Propagation work is about authoritative TTL and delegation gaps, not nginx worker counts. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius.

See also ACME HTTP-01 challenge failed 403 and acme.sh renewal failures and logs.

Why renewal failed

The ACME CA queries authoritative nameservers for a TXT token tied to each identifier. Partial updates on one NS in a multi-master setup produce intermittent validation failures. Document which nameserver set the CA queried using logs or dig +trace, because split providers frequently update only the UI-facing anycast pair while hidden secondaries serve stale TXT for the rest of the TTL window. Treat DNS validation as a distributed systems problem: consensus across NS sets matters more than single-resolver spot checks during renewal crunch.

Low TTL helps only when every nameserver agrees. Negative caching on busy resolvers can hide a correct authoritative answer for minutes after your panel shows success. Teams migrating to geo-steered DNS should pause issuance until every POP publishes identical _acme-challenge answers; otherwise Boulder succeeds intermittently and automation looks flaky instead of deterministic. When migrating DNS vendors, run parallel TXT publishing with canary tokens before moving production ACME accounts.

CNAME indirection is valid, but the token must appear on the final zone Boulder reads. Delegation mistakes are the dominant cause of false 'Let's Encrypt is slow' narratives. Keep a runbook snippet listing authoritative NS hostnames and API users allowed to edit TXT so weekend responders do not guess credentials.

Let's Encrypt queries authoritative nameservers directly during validation, but your certbot or cert-manager hook writes TXT only on the DNS provider API. If CNAME chains point at the wrong zone, or NS glue is slow, the CA sees stale or missing tokens while your panel shows green. DNS-01 succeeds only when every delegation hop returns the exact token string the ACME client generated for that order. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs.

Slow DNS propagation is not fixed by shortening certificate lifetime or switching to HTTP-01 without opening port 80 on every hostname. It is not the same as a rate limit error. It is not proof the domain is unregistered. It is not resolved by reinstalling certbot alone if the TXT never appears in the parent zone. External dig +trace must show the token before you blame Let's Encrypt.

Common causes

These patterns drive most acme dns challenge failed tickets. They explain why automation logs look green while browsers or APIs still break.

Operators created _acme-challenge TXT in the wrong zone because the marketing subdomain uses a CNAME to a CDN while the apex stays at the registrar. Automation updated a duplicate record with a trailing dot mismatch. Low TTL never got applied because the API call targeted a parked template zone. Delegated subdomains with CNAME to SaaS platforms sometimes require TXT at the provider alias target instead of the parent zone—runbooks copied from apex-only examples fail quietly.

Split-horizon DNS returns the challenge token on the internal view but the public authoritative servers still serve an empty TXT set. Secondary nameservers lag minutes behind the primary after API updates. GeoDNS sends the CA resolver to a POP that has not received the new record yet.

Wildcard orders require TXT at _acme-challenge.example.com while the runbook only updated per-host labels. Propagation monitors queried a resolver with aggressive negative caching and declared success prematurely. Multiple ACME clients fought over the same TXT name with different values, invalidating earlier orders.

Diagnose

Confirm the exact TXT value from your ACME client, then compare authoritative answers with what public resolvers return.

dig +short TXT _acme-challenge.example.com @ns1.yourdns.com
dig +short TXT _acme-challenge.example.com @1.1.1.1
dig +trace TXT _acme-challenge.example.com

Capture the exact TXT value your ACME client published and query it from at least two public resolvers plus the authoritative NS directly. If authoritative answers match but resolvers do not, wait for TTL or fix lame delegation. If authoritative answers are wrong, fix the API target zone before re-attempting finalize. Export a short table in the ticket: resolver queried, TXT seen, TTL remaining, and whether the value matches the current order token rather than a superseded attempt.

Fix step-by-step

Follow this sequence for acme dns-01 challenge propagation delays. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. List every SAN on the certificate and map each to the zone that must hold _acme-challenge.
2. Set TTL to 60s during rotation if the provider supports it.
3. Publish the TXT from the ACME client; remove stale tokens from abandoned orders.
4. Query each authoritative NS directly, then two public resolvers.
5. Fix CNAME chains that point at the wrong DNS account.
6. Re-run certbot certonly or wait for cert-manager to requeue the Challenge.
7. Verify HTTPS notAfter with external OpenSSL after Ready=True.
8. Restore normal TTL and document which API user owns challenge records.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

After issuance succeeds, confirm notAfter on the live name—not while TXT is still being debugged.

How to read the output

DNS-01 does not change what openssl shows on 443 until issuance succeeds. After validation, run echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject. During propagation debugging, compare dig TXT _acme-challenge.example.com @1.1.1.1 with dig @8.8.8.8 and with the nameservers listed in the zone SOA.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Identify the authoritative zone that must hold _acme-challenge for every name on the certificate, including delegations via CNAME. Set TTL to 60 seconds during cutovers if the provider allows. Generate a fresh order after clearing stale TXT values that belong to abandoned attempts.

Apply the token through the official API or automation hook, then verify with multiple public resolvers and with dig +trace from a bastion. Wait for SOA minimum TTL before triggering cert-manager or certbot finalize. Document which NS set Let us Encrypt actually queried from CA logs if available. During cutover, pause other DNS edits in the same zone to avoid racing API writes against automation hooks.

Re-run issuance, confirm the new leaf serial on the live listener, and restore normal TTL. Add external DNS checks for challenge names ahead of renewal windows. Monitor cert-manager Certificate Ready=False reasons mentioning DNS timeout.

What to automate

Monitor TXT presence on _acme-challenge labels before renewal windows open, not only TLS notAfter on 443. Run scheduled authoritative versus recursive TXT diffs for every _acme-challenge label on production lineages, storing JSON results for audit.

ssldays can alert on certificate expiry while you keep DNS challenge checks in CI—pair both so propagation gaps surface early. ssldays external TLS checks plus DNS challenge synthetics give coverage when only one layer would stay green.