ACME DNS-01 vs HTTP-01 is a choice about where a certificate authority should look for proof that you control a domain. HTTP-01 puts a short-lived file on the web server. DNS-01 publishes a short-lived TXT record in DNS.

HTTP-01 is usually simpler for one ordinary website. DNS-01 is required for wildcard certificates and often fits large or private fleets better, but it introduces DNS API credentials and propagation delays. The best challenge is the one your renewal system can complete automatically with the smallest useful permission.

Standards checked: RFC 8555 and Let’s Encrypt’s challenge guidance were reviewed on 29 October 2026. Provider-specific timing and redirect rules below are identified as Let’s Encrypt behavior.

What an ACME challenge proves

The Automatic Certificate Management Environment, or ACME, lets software request and renew public-key certificates. Before a certificate authority issues a certificate for a domain, it asks the ACME client to complete one or more challenges.

Each challenge includes a random token. The client combines that token with information derived from its ACME account key to create a key authorization. The certificate authority then checks a location that should be controllable only by someone who controls the domain’s web service or DNS.

Successful validation proves control at that moment. It does not prove that the requester owns the trademark, runs a safe website or will continue controlling the domain forever. Certificates therefore have limited validity and automated renewal repeats the check.

HTTP-01 in one request

For HTTP-01, the ACME client makes the key authorization available at this path:

http://example.com/.well-known/acme-challenge/<token>

The certificate authority performs an HTTP GET for that resource. If the response body matches the expected key authorization, the challenge can move to valid status.

RFC 8555 requires the initial connection to use TCP port 80. The challenge deliberately begins with HTTP rather than requiring a valid HTTPS certificate; obtaining that certificate is the task being bootstrapped.

The token is unique to the challenge and carries at least 128 bits of entropy under the standard. An ACME client should provision the response for the specific challenge rather than building a generic endpoint that reflects arbitrary URL tokens.

DNS-01 in one record

For DNS-01, the client publishes a TXT record under a fixed validation name:

_acme-challenge.example.com

The record value is a base64url-encoded digest derived from the key authorization. The certificate authority queries DNS and compares the TXT value with the expected result.

The proof is placed in DNS rather than on the web server. This lets a client validate a name even when the origin is private, port 80 is unavailable or the domain points at several independently managed servers.

It also enables wildcard certificates. A request for *.example.com cannot use HTTP-01, because the wildcard does not identify one HTTP host on which the authority can fetch a challenge file. DNS control covers the wildcard namespace.

Side-by-side comparison

Question HTTP-01 DNS-01
Proof location File under /.well-known/acme-challenge/ TXT at _acme-challenge.<name>
Required public service HTTP on port 80 Authoritative DNS
Wildcard certificate No Yes
Typical automation access Webroot, reverse proxy or challenge server DNS provider API
Multi-server concern Every possible validation target must serve the token Authoritative resolvers must publish the TXT value
Common delay Routing or proxy mismatch DNS propagation and cache timing
Main credential risk Ability to write or route the challenge path Ability to change DNS records
Private origin possible Usually no, because the CA must reach port 80 Yes, if public DNS can publish the proof

Neither method is universally more secure. The risk depends on how narrowly the automation is scoped and how reliably the proof reaches the certificate authority.

When HTTP-01 is the practical choice

HTTP-01 works well when a site already listens publicly on port 80 and the certificate client can place a file or intercept the challenge path.

Common patterns include:

  • a client writing into the site’s webroot;
  • a reverse proxy routing /.well-known/acme-challenge/ to a small validation service;
  • a hosting platform answering challenges for customer domains;
  • a load-balanced service distributing the token to every edge that can receive the request.

Let’s Encrypt describes HTTP-01 as its most common challenge and recommends it when an operator is unsure. The method is easy to automate with standard web servers and does not require a DNS provider API.

The operational weakness is routing. If example.com has several A or AAAA records, the authority can reach one of those addresses at its discretion. A challenge file present on only one node may fail from another validation vantage point.

Check IPv6 as well as IPv4. A stale AAAA record can send validation to a server that never received the token.

Port 80 and redirects

RFC 8555 fixes HTTP-01 to port 80. A public web service can redirect ordinary traffic to HTTPS while still answering the challenge path.

Let’s Encrypt says its implementation follows at most ten redirects and accepts redirects only to HTTP or HTTPS URLs on ports 80 or 443. When a redirect reaches HTTPS, its validator does not require the existing certificate to be valid because the challenge may be creating or repairing that certificate.

Those redirect details belong to Let’s Encrypt, not to every possible ACME authority. An ACME client used with another authority should follow that authority’s documentation.

Do not redirect the challenge path through an authentication page, a regional hostname that lacks the token or an application route that rewrites the response body.

When DNS-01 earns its complexity

DNS-01 is the right fit when you need:

  • a wildcard certificate;
  • validation for a service that is not exposed on port 80;
  • one central certificate service for many backends;
  • validation independent of application deployment;
  • delegation of validation to a dedicated DNS zone or service.

Let’s Encrypt follows standard DNS indirection for these checks. An operator can delegate _acme-challenge using CNAME or NS records to a separate zone that the certificate system controls.

That design can avoid handing broad credentials for the main zone to every web server. It can also move validation to a provider with faster update behavior while the production DNS provider remains unchanged.

The DNSSEC explainer describes how signed DNS data is authenticated. RFC 8555 recommends that ACME certificate authorities use DNSSEC-validating resolvers for challenge lookups, but DNSSEC is not a requirement placed on every applicant domain by the ACME standard.

DNS API credentials are the central risk

Automated DNS-01 needs a way to create and remove TXT records. Giving a web server a credential that can rewrite the entire zone increases the impact of a server compromise.

Prefer, in order:

  1. a provider token restricted to the exact zone and record operations needed;
  2. delegation of _acme-challenge to a validation-only zone;
  3. a separate certificate service that holds DNS credentials and distributes completed certificates;
  4. a manual DNS change only for exceptional, non-recurring issuance.

Manual DNS-01 is a poor renewal strategy. Certificates expire on a schedule, and a process that waits for a person is easy to miss.

Store the API credential outside the webroot, rotate it, log changes and remove obsolete challenge records. If the provider cannot restrict a token to TXT updates or a validation subzone, weigh that privilege against the convenience of wildcard issuance.

Why DNS propagation causes failures

A DNS update is not a single global write. The automation changes an authoritative source, but the certificate authority can query different authoritative servers or recursive paths.

Failures can occur when:

  • one authoritative server has not received the new record;
  • a previous TXT answer remains cached;
  • the provider reports success before all nameservers publish the value;
  • two concurrent renewals overwrite each other’s TXT records;
  • the client deletes the record before all validation checks finish;
  • a CNAME or delegated zone points somewhere unexpected.

Multiple TXT values can coexist at the same challenge name. That matters when several certificate orders validate the same domain at once. Automation should add and remove its own value rather than replace the whole RRset blindly.

The client should poll authoritative DNS until the expected value is visible and allow for the provider’s real propagation behavior. A fixed sleep can be either too short during an incident or wastefully long when the update is immediate.

Wildcard does not mean every hostname

A certificate for *.example.com matches one label below example.com, such as api.example.com. It does not match the apex example.com, and it does not match a.b.example.com.

An order commonly includes both example.com and *.example.com. The CA may present separate DNS-01 challenge objects even though their TXT records use the same _acme-challenge.example.com name. The client must preserve all currently required values until each authorization completes.

Choose a wildcard because it matches the deployment model, not simply to reduce the number of certificates. A wildcard private key has a wider blast radius if copied across many services.

Load balancers and container platforms

HTTP-01 in a dynamic platform needs a shared answer at every ingress path. A rolling deployment can remove the pod holding the token before validation completes. A CDN can cache an old response or route a challenge request to an origin that lacks the file.

A dedicated challenge responder behind the ingress is often more reliable than copying files into application containers. The route should bypass authentication, body rewriting and aggressive caching while remaining limited to the exact challenge prefix.

DNS-01 decouples validation from those web routes, but it shifts reliability to the DNS API and certificate distribution. The completed certificate and private key still need a secure path to every terminator that uses them.

Cleanup and failure recovery

Challenge resources are temporary. Remove the file or TXT value after the authorization reaches a final state. Leaving a stale token does not normally let someone reuse it for a new order, because new challenges use new random tokens and account-key material, but stale records make operations harder to audit.

When validation fails:

  • confirm the exact identifier in the order;
  • read the challenge error returned by the ACME server;
  • query every A, AAAA or authoritative DNS path involved;
  • verify the expected token-derived value, not merely that some record exists;
  • check that the record remains available until validation completes;
  • request a fresh challenge only after fixing the route or propagation issue.

Avoid rapid blind retries. They consume rate limits and can leave overlapping challenge state that hides the original problem.

A decision checklist

Choose HTTP-01 when:

  • you need ordinary host certificates, not wildcards;
  • port 80 is publicly reachable;
  • one controlled ingress can serve the token everywhere;
  • you want to avoid DNS API credentials.

Choose DNS-01 when:

  • you need a wildcard certificate;
  • the origin is private or port 80 is unavailable;
  • certificate issuance is centralised across many services;
  • you can automate narrowly scoped DNS changes;
  • your client can wait for authoritative propagation.

Whichever method you choose, test renewal rather than only first issuance. The certificate lifecycle is automated only when challenge creation, validation, cleanup, certificate deployment and reload all succeed without a manual step.