ACME DNS Challenge Readiness Check

DNS-01 validation proves domain control by putting a short TXT value into the Domain Name System instead of serving a challenge file over HTTP. That makes it useful for wildcard certificates, private origins, load-balanced services, and environments where an ACME client can update DNS more reliably than it can expose a web path. The certificate authority is not checking whether the website loads. It is checking whether the expected TXT proof is visible at the DNS owner name for the identifier being authorized.

The owner name is easy to get almost right. A normal name such as www.example.com is checked below _acme-challenge.www.example.com. A wildcard such as *.example.com is checked below _acme-challenge.example.com, because the wildcard marker is removed before the challenge owner is formed. A TXT value at _acme-challenge.*.example.com, at the zone apex, or under the wrong subdomain can look sensible in a DNS console while still being invisible to validation.

Many production DNS-01 setups are not direct TXT records. A team may publish the TXT value directly at the challenge owner, point that owner through a CNAME to a validation service, or delegate the _acme-challenge name as a tiny NS-controlled zone. Delegation can make automation cleaner because the main DNS zone stays locked down while a certificate platform updates a narrower validation zone. The tradeoff is that route shape now matters as much as the value itself.

Identifier

The certificate name being authorized, such as example.com, www.example.com, or *.example.com.

Challenge owner

The DNS name where the DNS-01 proof is expected, usually under _acme-challenge.

Terminal TXT owner

The final name that should contain the TXT value after any accepted CNAME route is followed.

Resolver view

The DNS answer a public resolver returns at the time of the check, including cached positive or missing answers.

Propagation delays are only one class of failure. A resolver may still remember that a TXT record was missing, but a CNAME loop, a CNAME owner mixed with TXT records, an unsupported delegation style, or an old TXT value will not fix itself by waiting. Good DNS-01 troubleshooting separates temporary cache disagreement from structural DNS shape problems.

A readiness result should be treated as a point-in-time clue. Public resolvers can disagree, DNS anycast can return different answers from different locations, and a certificate authority may query from a vantage point that is not represented by the resolvers you sampled. Strong evidence is still useful: it tells you whether to retry the order, wait for caches, or change the DNS record layout before spending another validation attempt.

How to Use This Tool:

Start with the exact certificate identifier, then add only the DNS details that change the validation route or token comparison.

1. Enter the Identifier from the ACME order. Use names such as example.com, www.example.com, or *.example.com; the page normalizes wildcard names before building the challenge owner.
2. Choose the ACME profile that matches the client or certificate platform. Let's Encrypt DNS-01 accepts direct TXT, CNAME delegation, and NS delegation. CNAME-following client accepts CNAME routes. Strict TXT-only client expects a direct TXT owner.
3. Paste the Expected token when you have the current DNS-01 TXT value. Leave it blank only when you want to inspect whether the route can publish TXT data at all.
4. Open Advanced when your validation system uses a different challenge host, a pinned resolver, a planned route style, or a custom CNAME depth limit. The depth control accepts 2 to 6 hops in the form.
5. Leave Compare resolvers on after recent DNS edits. Resolver comparison checks Cloudflare and Google Public DNS side by side so propagation drift is visible before you retry issuance.
6. Select Check Readiness. If the owner cannot be derived or no resolver answer can be collected, correct the identifier or DNS name before checking again.
7. Read Challenge Route first for the owner, route, terminal TXT owner, visible TXT values, and primary recommendation. Use Resolver Views, Retry Window, and ACME DNS Runbook when you need resolver-by-resolver evidence or command-line follow-up checks.

Interpreting Results:

The headline state is a triage label. The owner name, terminal TXT owner, profile fit, and resolver agreement decide the next action.

Resolver Views is most useful when one public resolver has caught up and another has not. A primary ready view can still become an overall waiting state when resolver comparison is enabled and the compared resolver does not agree. Readiness Signal Split summarizes token visibility, topology, resolver agreement, and profile fit as a compact chart; treat it as a diagnostic summary of the same evidence, not as a separate DNS test.

Technical Details:

ACME DNS-01 validation centers on a TXT resource record below a validation domain name. The ACME client receives a challenge token, combines it with account-key material to form a key authorization, hashes that authorization with SHA-256, and publishes the base64url digest as the TXT value. A domain name alone cannot reveal the correct value for the current order, so any readiness check must compare DNS answers against the current value supplied by the ACME workflow.

DNS route shape determines where that TXT value must appear. A direct route looks at the challenge owner itself. A CNAME route follows the alias chain until it reaches the terminal TXT owner. An NS route treats the challenge owner as a delegated validation zone when the selected profile allows that pattern. CNAME owners have a stricter DNS rule: an owner name that has a CNAME should not also have TXT or NS data at the same owner, because the alias and non-alias data would conflict.

Rule Core:

Profile and Boundary Logic:

Negative caching is the reason a recently added TXT record can still look absent. When a resolver previously saw no matching record, it can cache that missing-answer response. The SOA record in or near the response gives a practical retry hint because DNS negative answers use SOA timing information to bound how long absence can remain cached.

The command runbook mirrors the public evidence path with dig checks for owner TXT, owner CNAME, delegated NS, terminal TXT, trace output, and pinned public resolvers. Those commands are useful when an ACME client or CA still fails after the page shows readiness, because they reveal whether the same owner and terminal name resolve outside the browser resolver view.

Privacy and Accuracy Notes:

DNS questions for the challenge owner, delegation targets, and related SOA names are sent from your browser to the selected public resolver views. The page does not log in to your DNS provider, change records, or need provider API credentials. The expected TXT value is used to compare visible answers; it is not part of the DNS question itself.

• Certificate authorities can query from networks that are not represented by Cloudflare or Google Public DNS, so Ready is strong evidence rather than a universal guarantee.
• DNSSEC validation, CAA policy, ACME account status, certificate order status, and CA rate limits are outside this check.
• Without an expected token, visible TXT records prove that text can be published at the route, not that the current order value is correct.
• Challenge values can remain in browser history, copied exports, or shared URLs while you use the page, so handle current order tokens as operational data.

Worked Examples:

A direct order for example.com checks _acme-challenge.example.com. If the expected value is abc123 and the primary resolver sees the TXT value abc123 at that owner, the route and token checks can report Ready. If the same owner contains old456, the route may be usable but the current token remains mismatched.

A wildcard request for *.api.example.com checks _acme-challenge.api.example.com. If that owner CNAMEs to validation.example.net and the expected TXT value appears at the terminal owner, the Let's Encrypt and CNAME-following profiles can treat the route as ready. Strict TXT-only remains blocked because it does not accept the delegated route.

A recent update can produce a waiting result even when the DNS record is correct at the authoritative provider. Cloudflare may show the new TXT value while Google Public DNS still returns no value and a negative-cache hint. Resolver comparison points to a wait-and-rerun action instead of a record rewrite.

A mixed CNAME owner is a structural failure. If _acme-challenge.example.com has both a CNAME and a TXT record, removing the conflicting record or changing the route is required before propagation time can help.

FAQ:

Glossary:

ACME

The protocol many certificate authorities and clients use to automate certificate issuance, renewal, and related certificate-management actions.

DNS-01

An ACME challenge type that proves domain control by publishing a TXT value in DNS.

Challenge owner

The DNS name where the DNS-01 proof should be found, normally under _acme-challenge.

Terminal TXT owner

The final DNS owner that should hold the TXT value after accepted CNAME delegation is followed.

CNAME delegation

A setup where the challenge owner points to another DNS owner that holds the TXT proof.

NS delegation

A setup where the challenge owner is delegated to separate nameservers as a validation-specific zone.

Negative caching

Resolver caching of a missing-answer response, which can keep a new TXT record looking absent until the cache expires.