Introduction

When cert-manager reports waiting for http-01 propagation: dial tcp: no such host, the failure is usually simpler than it looks: the hostname used for the ACME challenge does not resolve correctly from the point of view of the checker. HTTP-01 depends on DNS and HTTP routing both being correct, so a broken name lookup stops the challenge before the token can even be fetched.

What HTTP-01 Needs to Work

For an HTTP-01 challenge, the certificate authority must be able to reach:

http://your-domain/.well-known/acme-challenge/...

That means all of the following must be true:

• the requested hostname has a valid public DNS record,
• the record points to the correct ingress or load balancer,
• cert-manager created the temporary solver route,
• inbound HTTP on port 80 reaches that solver.

If DNS lookup fails, cert-manager often surfaces that as dial tcp: no such host during propagation checks.

What the Error Usually Means

no such host is a name-resolution error, not an HTTP status problem. In other words, the system could not resolve the hostname to an IP address at all.

Common causes include:

• missing A or AAAA records,
• a typo in the certificate's dnsNames,
• DNS changes that have not propagated yet,
• an internal-only DNS name used for a public ACME challenge,
• split-horizon DNS where cert-manager and the public internet see different answers.

Verify DNS First

Before looking at Ingress resources, check whether the hostname resolves publicly.

dig +short example.com
nslookup example.com

If those commands return nothing useful from a normal public resolver, cert-manager cannot complete HTTP-01 either.

Then inspect the challenge objects:

kubectl get challenge
kubectl describe challenge <challenge-name>
kubectl describe order <order-name>

The describe output usually tells you whether the solver ingress was created and what hostname is being validated.

Check the Ingress Path

Once DNS resolves, make sure HTTP traffic reaches the solver endpoint. cert-manager normally creates a temporary solver service and ingress rule for the challenge.

kubectl get ingress
kubectl get svc
kubectl get pods -A | grep acme

If the hostname resolves to the wrong load balancer or the wrong ingress controller, the challenge path will still fail even though DNS exists.

A quick manual check is:

curl -I http://example.com/.well-known/acme-challenge/test

You do not need a real token for this sanity check. You just want to confirm that the request is reaching the expected ingress path instead of another service or a DNS error page.

Ingress Class Mismatches

A common Kubernetes-specific problem is that cert-manager creates the solver ingress, but the wrong ingress controller picks it up, or no controller picks it up at all.

For example, a solver configuration may need the correct ingress class:

1solvers:
2  - http01:
3      ingress:
4        ingressClassName: nginx

If your cluster uses a different class name, the temporary challenge route may never become reachable at the hostname you expect.

Public DNS Versus Internal DNS

HTTP-01 is intended for publicly reachable names. If example.internal only resolves inside a private network, Let's Encrypt cannot validate it over HTTP-01.

That is where many teams waste time. The Kubernetes resources can look perfectly healthy, but the hostname itself is not resolvable on the public internet.

In that case, the fix is not more ingress tuning. The fix is either:

• publish a real public DNS record, or
• switch to DNS-01 if your domain and validation model support it better.

cert-manager Resolver Nuances

cert-manager performs its own propagation checks before the ACME server validates the challenge. If your cluster nodes use resolvers that see a different DNS view than the outside world, those checks can mislead you.

That matters in environments with custom /etc/resolv.conf, split DNS, or unusual recursive resolvers. If the challenge only works from one DNS view, HTTP-01 becomes fragile.

Common Pitfalls

The biggest mistake is debugging ingress rules before confirming that the hostname resolves publicly. no such host points at DNS first.

Another issue is requesting certificates for hostnames that only exist in internal DNS. Public ACME validation cannot succeed against names the certificate authority cannot resolve.

Teams also forget ingress-class alignment. If cert-manager writes the temporary solver ingress for the wrong controller, the challenge path never becomes live even after DNS is correct.

Summary

• 'dial tcp: no such host usually means DNS resolution failed before HTTP validation could happen.'
• Check public A and AAAA records before investigating the solver pod.
• Confirm that cert-manager created the temporary challenge ingress and service.
• Make sure the solver uses the correct ingress class and points at the right load balancer.
• If the hostname is private-only, HTTP-01 is the wrong validation method.