Should organisations use HTTP-01 or DNS-01 for automated certificate validation?

How HTTP-01 and DNS-01 Differ in Practice

HTTP-01 validates control of a domain by serving a challenge response over plain HTTP, so it is best suited to a service that is directly reachable on port 80 and has a simple public edge. DNS-01 validates control by publishing a DNS TXT record, which makes it the better fit when the certificate must cover wildcards, internal hosts, or services that are not directly exposed.

The choice is therefore not just about convenience. It also changes the trust boundary for automation: HTTP-01 keeps the validation path at the web server edge, while DNS-01 shifts control to the DNS platform and the API token used to update records. For teams running automated issuance at scale, that difference affects blast radius, operational ownership, and recovery when validation fails.

When the service is public and stable, HTTP-01 is usually the lower-friction option because it avoids giving certificate automation access to DNS. When the service estate is distributed, ephemeral, or fronted by a CDN, DNS-01 is often the only practical path because it does not depend on inbound reachability to each host. That is why certificate operations should be designed around the actual deployment model, not around the validation method that seems simplest in isolation.

What the Validation Method Changes About Certificate Operations

HTTP-01 tends to fit environments where web delivery and certificate issuance live close together. It is easier to reason about when a single edge service can answer the challenge consistently and when port 80 is intentionally available. The main operational constraint is that the server handling the challenge must be the one ACME expects to reach, so routing, redirects, CDN behaviour, and edge caching can all interfere.

DNS-01 is more flexible because it decouples validation from web reachability. That flexibility is especially valuable for wildcard certificates and private services, but it also introduces dependency on DNS automation quality. If the DNS provider API is slow, unavailable, rate-limited, or misconfigured, issuance and renewal can fail even when the application layer is healthy.

For teams that manage many certificates, the practical question is which system already has the right operational ownership. If web operations own the host but not DNS, HTTP-01 may be simpler to govern. If platform engineering already automates DNS and needs broad certificate coverage, DNS-01 is usually the more scalable pattern. For certificate lifecycle and renewal planning, Machine Identity, PKI and Certificate Lifecycle Guide is a useful reference point.

How to Decide Without Creating a New Risk Surface

The cleanest decision rule is operational first, not ideological. Use HTTP-01 when the host is public, port 80 is acceptable, and you only need ordinary single-name certificates. Use DNS-01 when you need wildcard coverage, hidden origin services, or a setup where the web server is not the right place to prove domain control.

The hidden risk with DNS-01 is credential governance. The DNS API token can become a high-value secret because whoever controls it can alter validation records and, depending on the provider and scope, potentially influence other DNS changes too. That means the automation token should be treated as sensitive identity material, not as a throwaway script variable. IANA is a useful general reference for protocol and registry context, but the security decision here is really about who can write DNS and how tightly that access is constrained.

If you are building for workload or service identity rather than just public website validation, the broader pattern is similar: separate the control plane from the application plane wherever you can, and keep the validation mechanism as narrow as possible. Guide to SPIFFE and SPIRE is relevant when you are thinking about identity, trust, and automation beyond a single certificate renewal flow.

Risk and Threat Considerations

The main risk is not the validation method itself, but the reach it gives to the automation path. HTTP-01 can fail or be abused when routing, redirects, or edge infrastructure prevent the challenge from reaching the expected service. DNS-01 can fail more quietly, because compromise or misuse of the DNS token can redirect validation at scale or expose broader DNS administration depending on token scope.

Failure mechanism: HTTP-01 depends on a reachable web endpoint, so any change in reverse proxying, CDN behaviour, port 80 availability, or host routing can break renewal. DNS-01 depends on a writable DNS control path, so weak token protection, overbroad permissions, or poor secret rotation can turn certificate automation into a high-impact access path.

Impact: The result can be certificate renewal failure, service outage, or an expanded attack surface if an attacker obtains the DNS API token and uses it to manipulate validation records. In practice, the more automated and multi-environment the estate, the more important it becomes to protect the DNS path like any other privileged credentialed integration.

Practitioner Guidance

Decision rule: Prefer HTTP-01 for straightforward public web services that already expose port 80 and do not need wildcard certificates; switch to DNS-01 when deployment reality, not preference, requires it.

What to verify: Before standardising on DNS-01, confirm that the DNS API token is scoped to only the zones and record types needed for validation, and that rotation is operationally tested. If you cannot describe who owns the token and how it is revoked, the automation design is incomplete.

What practitioners underestimate: DNS-01 is often chosen for convenience, but its real advantage is coverage. The trade-off is that certificate issuance becomes dependent on a privileged secret path, so the right control objective is not just successful validation, it is constrained, auditable, and recoverable validation.

Practitioner takeaway: Choose the method that matches the deployment model, then govern the validation channel as part of your certificate lifecycle, not as an implementation detail.

Related resources from NHI Mgmt Group

• When is a domain validated certificate enough, and when should organisations use stronger validation?
• When should organisations move beyond basic certificate checks and use deeper SSL validation?
• What breaks when organisations use SSO without proper transport encryption or certificate validation?
• Should organisations use persistent DNS validation records or recreate them every time?