{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
Use one public name such as example.com, www.example.com, or *.example.com.
Let's Encrypt accepts direct TXT, CNAME, and NS routes; stricter profiles narrow that set.
Optional and session-only. It is not written to the shareable URL.

{{ workflowFeedback }}

Leave blank to derive the challenge owner from the certificate identifier.
Choose a browser-compatible public JSON DNS-over-HTTPS provider.
Comparison warns on disagreement but does not replace authoritative DNS traces.
{{ compareResolversBool ? 'Cloudflare and Google' : 'Primary resolver only' }}
A mismatch adds a review finding without changing the observed DNS answer.
Use 2-6 hops. The default four follows the existing operational boundary.
Use 2000-12000 milliseconds. The default 6000 milliseconds covers both resolver views.
ms
CheckStatusEvidenceNext actionCopy
{{ row.label }}{{ row.status }}{{ row.evidence }}{{ row.action }}
ResolverVerdictRouteTXT viewRetry hintCopy
{{ row.resolver }}{{ row.verdict }}{{ row.route }}{{ row.txt_view }}{{ row.retry_hint }}
CheckCommandWhyCopy
{{ row.check }}{{ row.command }}{{ row.why }}
ACME HTTP 01 Readiness Validator Check ACME HTTP-01 retry readiness with a weighted evidence review of the public challenge route and a clear fix-before-retry verdict.
Alternative DCV Checker Check alternative certificate DCV proofs across DNS and web paths, including CSR-derived values and per-host mismatch or transport evidence.
MTA-STS Validator Check an email domain's MTA-STS TXT and HTTPS policy, then review MX patterns and the policy-host certificate before enforcement.
Certificate Inventory Expiry Checker Review a certificate inventory CSV locally to rank renewal urgency and flag ownership, manual-process, invalid-date and public-lifetime risks.

A DNS-01 authorization succeeds only when a certificate authority can retrieve the current challenge value from public DNS. The record belongs below _acme-challenge for the identifier being validated. A wildcard such as *.example.com therefore uses _acme-challenge.example.com, without the literal asterisk.

The visible TXT value is derived from the current Automatic Certificate Management Environment (ACME) order and account key. An older value at the right owner is still wrong. Several TXT records may coexist during overlapping authorizations, but at least one returned value must exactly match the active challenge.

Challenge owner
The DNS name queried for the proof, normally _acme-challenge followed by the certificate identifier.
Terminal owner
The final name that supplies TXT data after an accepted CNAME delegation.
Negative cache
A resolver may remember that a record did not exist. The zone's SOA data can provide a useful waiting hint, but caches differ.

Delegation can separate certificate automation from the main DNS provider. Let's Encrypt documents both CNAME and NS delegation for DNS-01, while another ACME client or certificate authority may require direct TXT data or accept only CNAME delegation. A valid DNS route must therefore match the policy of the issuer handling the order.

Propagation is not one global event. Recursive resolvers can hold different cached answers, anycast can send queries to different sites, and a delegated zone can be correct while a stale cache still returns no TXT value. Comparing two public recursive resolvers can expose disagreement, but it does not reproduce the certificate authority's authoritative or multi-perspective checks.

Readiness is a preflight judgment based on sampled public DNS. A matching result supports a retry; it cannot guarantee issuance after the token, delegation, authoritative data, or cache state changes.

How to Use This Tool:

Use the identifier and TXT value from one current ACME authorization.

  1. Enter the Certificate identifier. Leave Challenge host override blank unless the challenge owner must be derived from a different host.
  2. Choose the ACME profile and Expected route. Use the issuer or client policy for the active order rather than the shape of a previous setup.
  3. Paste the current Expected TXT value. Leaving it blank changes the check to discovery only, where any visible TXT value counts as present.
  4. Select the primary public resolver and enable Compare resolvers when cache disagreement matters. Start the check only after the intended record has been published.
  5. Read the overall readiness label, then resolve any blocked route, TXT mismatch, or resolver disagreement before asking the ACME service to validate again.

Interpreting Results:

  • Ready means the primary resolver returned an accepted route and matching TXT evidence, the selected route expectation matched, and compared resolvers agreed.
  • Waiting means no blocking topology was found, but a TXT value is missing or mismatched, the observed route differs from the plan, or the sampled resolver views disagree.
  • Blocked means the selected profile rejects the route or DNS contains a structural problem such as conflicting CNAME data, a CNAME loop, or a chain beyond the selected limit.

A negative-cache duration is only a retry hint and does not change the verdict. Before a production retry, confirm the authoritative path when resolver views disagree or when the certificate authority reports a different result.

Technical Details:

DNS-01 binds an ACME authorization to a TXT resource record. RFC 8555 defines the owner by prepending _acme-challenge to the identifier and requires one returned TXT value to match the base64url-encoded SHA-256 digest of the key authorization.

Mechanism Core:

The check starts at the challenge owner and queries TXT, CNAME, and NS through the selected DNS-over-HTTPS resolver. A single CNAME is followed until TXT data or a terminal owner appears. NS at the original owner is treated as delegation when no CNAME is present.

Observed routeLet's Encrypt DNS-01Direct TXT or CNAME clientDirect TXT only
Direct owner or direct TXTAcceptedAcceptedAccepted
CNAME delegationAcceptedAcceptedBlocked
NS delegationAcceptedBlockedBlocked

A CNAME at the same owner as TXT, NS, or more than one CNAME target is treated as conflicting data. Repeated targets form a loop. The configurable traversal limit accepts 2 to 6 hops; reaching the limit while another CNAME remains produces a blocked depth result.

Rule Core:

RulePass conditionNon-pass result
Route topologyNo conflict, loop, or depth failure and the profile accepts the routeStructural or profile incompatibility is Blocked
TXT evidenceExact expected value is present, or any TXT value is present in discovery-only modeMissing or nonmatching TXT is Waiting
Expected routeObserved route matches the selected intent; direct owner and direct TXT both satisfy direct intentA different accepted route is Waiting
Resolver agreementCompared views have the same verdict, route, terminal owner, and TXT setDifferent sampled views are Waiting

The overall result is Blocked when any evaluated rule fails. With no failure, any warning produces Waiting; only an all-pass set produces Ready. The negative-cache row is informational and never upgrades or downgrades that result.

When no TXT answer is visible, the resolver's SOA response is inspected. The retry hint uses the smaller of the SOA record TTL and its MINIMUM field when both are available, following DNS negative-caching semantics. Another resolver or authoritative server can still have a different cache state.

The request timeout accepts 2,000 to 12,000 milliseconds. Resolver comparison samples Cloudflare and Google Public DNS; it is evidence of public-recursive convergence, not proof of every authoritative server or certificate-authority network perspective.

Privacy and Accuracy Notes:

The certificate identifier, challenge owner, and queried record types are sent directly from the browser to the selected public DNS resolver. Resolver comparison sends the same public DNS questions to both supported resolvers.

  • The expected TXT value is optional, remains in the current session, and is excluded from the shareable URL.
  • DNS answers are requested without browser credentials and without cache reuse by the page, but the resolver applies its own logging and cache policies.
  • The check does not contact the ACME account, inspect the order state, validate DNSSEC itself, or reproduce the certificate authority's full network perspective.
  • Do not leave obsolete challenge values published indefinitely; remove them after the active authorization no longer needs them.

Worked Examples:

CNAME route with one stale resolver

A wildcard order for *.example.com delegates _acme-challenge.example.com to a validation zone. Cloudflare reaches the terminal owner and returns the current token, while Google still returns no TXT value. The route and primary TXT check can pass, but resolver agreement remains a warning, so the overall result is Waiting until the views converge or an authoritative trace explains the difference.

References: