Issuing Kubernetes Certificates via DNS Challenge

TL;DR

The DNS-01 challenge validates a domain using a TXT record and does not require a publicly accessible HTTP application. This is particularly relevant when the ayedo Edge Cloud handles public traffic and terminates TLS while the Kubernetes cluster remains isolated. Clear responsibilities for DNS, certificates, and TLS are crucial.

A certificate for a Kubernetes service is not successfully issued just because an ingress is internally accessible. ACME processes validate a domain through a defined network path. With HTTP-01, the validation service must reach the application over port 80. With DNS-01, a correctly set TXT record under _acme-challenge suffices. This fundamentally changes the requirements for network topology, firewall rules, and the boundaries of responsibility between the cluster and the edge.

HTTP-01 and DNS-01 Validate Different Paths

With HTTP-01, the ACME client places a random challenge under /.well-known/acme-challenge/. The certificate authority accesses this URL via the domain to be validated. For this, the domain must publicly point to an accessible HTTP endpoint. An ingress or gateway must correctly route the request, port 80 must not be blocked, and upstream components must not alter or reject the challenge path.

DNS-01, on the other hand, uses a TXT record under _acme-challenge.<domain>. The certificate authority queries this record via DNS. The actual HTTP service does not need to be reachable during validation. This is suitable for internal backends, isolated clusters, wildcard certificates, and environments where port 80 is deliberately not published.

The difference is architecturally significant: HTTP-01 ties issuance to the application’s data path. DNS-01 ties it to control over the authoritative DNS zone. A network path to the ingress is not required with DNS-01, but DNS changes must be automated and secure.

DNS Validation Shifts the Responsibility Boundary

For DNS-01, the ACME client needs access to the DNS zone where the TXT record is created. In Kubernetes , this typically occurs via a certificate controller or a separate ACME client. This component does not necessarily have to be in the same responsibility area as the authoritative nameservers. However, it needs a controlled way to set the required record and remove it after validation.

This creates a different security requirement than with HTTP-01. Instead of providing a public HTTP endpoint for the challenge, a component gains write access to DNS. These rights should be limited to the necessary zones or record types. Incorrect permissions can have broader impacts than a misrouted challenge path, as DNS changes can affect multiple services or domains.

The distribution of DNS also plays a role. With Anycast DNS or multi-provider DNS, the TXT record must be visible through the actually authoritative systems. The client must not only check a single resolver or a local view. Delays in replication can result in the certificate authority not seeing the record, even though it is already present from an internal perspective.

Edge, TLS Termination, and Kubernetes Are Separate Layers

When a public domain points to the ayedo Edge Cloud, the public entry point is before the Kubernetes cluster . The edge processes incoming traffic and can terminate TLS before requests are forwarded over the network to the backend. The certificate for the public hostname must then be available at the TLS termination. It is not enough to store a certificate only in the Kubernetes ingress if the connection already ends at the edge.

DNS-01 is independent of whether the backend is publicly accessible in this model. The domain can point to the edge while the ACME client in the cluster or a separate operational area manages the DNS challenge record. The edge then needs the issued certificate for TLS termination—either through a defined certificate process or through appropriate management outside the cluster. Which component performs this transfer is an operational decision and should not be implicitly assumed.

The ayedo Edge Cloud is not limited to the Kubernetes cluster. It can also be used in front of clusters from other providers or in front of proprietary infrastructure. This allows DNS validation, public entry, and compute operations to be modeled as separate areas of responsibility.

Requirements for Domains, Ingress, and Gateway

A certificate request must exactly match the DNS names under which a service should be accessible. If api.example.org points to an ingress or gateway host, this hostname must be considered both in the certificate and in the TLS configuration. A certificate for example.org does not automatically cover api.example.org. Wildcard certificates can cover multiple subdomains but require DNS-01 with ACME.

With HTTP-01, the hostname must actually route to the responsible ingress or gateway during validation. An ayedo Edge Cloud in front can terminate or forward the request; routing, TLS configuration, and challenge path must match. Backend cloaking or a restrictive firewall is not fundamentally incompatible with HTTP-01 but can prevent validation if the ACME request does not reach the expected path.

With DNS-01, correct delegation of the domain and publication of the TXT record is sufficient. The A or AAAA record does not need to point to a publicly accessible cluster. Nevertheless, the final data route should already be consistently planned: certificate issuance, TLS termination at the edge, and forwarding to the gateway are separate steps that must use the same hostname.

Practical Scenario: Public Edge, Private Cluster

A company operates shop.example.org in a Kubernetes cluster without direct internet accessibility. The domain points to the ayedo Edge Cloud. There, TLS is terminated, DDoS protection and WAF are applied, and then the traffic is forwarded to the gateway in the private cluster.

HTTP-01 would only be possible in this topology if the edge correctly transports the challenge path to the gateway and the cluster remains accessible during validation. DNS-01 reduces this coupling: the ACME client sets the TXT record without needing to open port 80 or the backend publicly. The certificate is then provided for TLS termination at the edge. If the connection between the edge and backend is also to be encrypted, an additional certificate and trust concept for this connection is required.

FAQ

Is DNS-01 necessary for every Kubernetes certificate?

No. HTTP-01 suffices for publicly accessible hostnames without wildcard requirements. DNS-01 is advisable when the cluster is isolated or wildcard certificates are needed.

Does the DNS-01 client have to run in the cluster?

No. It can run in the cluster, on a central platform , or in a separate operational process. Secure write access to the authoritative DNS zone is crucial.

Where is the certificate located for TLS termination at the edge?

It must be available where the TLS connection ends. If terminated at the edge, it is the edge level; a certificate solely in the Kubernetes gateway is not sufficient.

Conclusion

DNS-01 is not an alternative switch for HTTP-01 but a different validation model with different boundaries of responsibility and security. It decouples certificate issuance from the public accessibility of the ingress or gateway but requires controlled DNS access. In an architecture with the ayedo Edge Cloud, public entry, TLS termination, and Kubernetes compute can be clearly separated. It is crucial to plan these layers together but not to mix them operationally.