Automating ACME DNS Challenges with Kubernetes

TL;DR

The DNS-01 challenge automates the issuance and renewal of TLS certificates without requiring a service to be accessible over HTTP. In Kubernetes , a certificate controller manages the lifecycle. An edge platform like the ayedo Edge Cloud provides DNS, public accessibility, and optionally TLS termination, separately from the cluster.

Introduction

Manually requesting and renewing TLS certificates is not a viable operational strategy in Kubernetes . Certificates expire, responsibilities are spread across multiple teams, and dynamic deployments can easily lead to inconsistencies between DNS, ingress, and secret management. The DNS-01 challenge shifts validation to a controlled DNS change: the ACME client publishes a TXT record proving control over a domain. This allows for the validation of wildcard certificates and services that are not publicly accessible via HTTP. The real challenge lies not in the ACME protocol, but in secure and traceable automation across DNS and Kubernetes .

1. DNS-01 vs. HTTP-01: Architectural Changes

With an HTTP-01 challenge, the certificate authority must reach a defined path over port 80, requiring a functioning public route to the responsible ingress. The DNS-01 challenge, on the other hand, uses a TXT record under _acme-challenge.<domain>. The ACME client generates a token, publishes it in DNS, and waits for the change to be visible for validation.

This decouples certificate issuance from the HTTP data path. A cluster can be behind a load balancer, a private network, or an additional protection layer. Wildcard certificates like *.example.com can also be validated via DNS-01, which is not possible with HTTP-01.

The trade-off is a greater responsibility for DNS. Incorrect zones, delayed propagation, or competing TXT records can lead to validation errors. DNS thus becomes not just a name resolution service but a component of the certificate process.

2. Automating the Certificate Lifecycle in Kubernetes

In Kubernetes , automation is typically implemented through a certificate controller. A declarative object describes domain names, issuers, and desired certificates. The controller creates ACME orders and challenges, sets up the necessary TXT records, and writes the completed certificate into a Kubernetes secret.

For operations, it is crucial that issuance and renewal use the same process. A certificate issued once reduces manual effort initially but does not solve the expiration issue. The controller must renew early, make errors visible, and retry after temporary DNS or ACME problems.

The secrets must also be available where TLS is terminated. If termination occurs in the Kubernetes ingress, the certificates reside in the cluster. If TLS is terminated at a preceding edge, certificate management belongs to the edge layer. Both models are technically feasible but require clear responsibilities for certificate storage, access protection, rotation, and monitoring.

3. Secure and Provider-Independent DNS Access

For DNS-01, the Kubernetes controller needs write access to the relevant DNS zones. A global DNS administrator access is unsuitable: a compromised controller could alter any records. Dedicated, minimally privileged credentials and a restriction to necessary zones or record types are preferable.

The DNS architecture also affects automation. With multiple authoritative providers, changes must be published consistently. Otherwise, the certificate authority queries a nameserver where the TXT record is still missing. Anycast DNS and multi-provider DNS can increase resolution availability but do not replace correct synchronization and propagation verification.

The ayedo Edge Cloud offers Anycast DNS and multi-provider DNS as part of its edge platform. [Kubernetes] workloads can run in ayedo Managed Kubernetes or in clusters operated by other providers. For certificate design, it remains important whether ayedo DNS manages the authoritative zone and how the controller or a delegated challenge mechanism accesses it.

4. Cleanly Separating Edge and Cluster Termination

DNS-01 answers the question of how a domain is validated. It does not determine where subsequent TLS traffic is terminated. This decision should be made independently. If Kubernetes terminates TLS itself, the ingress must load the correct secret and update it without interruption upon renewal. If the edge terminates, certificates and public TLS configuration remain outside the cluster; backend traffic can then be protected and distributed.

The ayedo Edge Cloud handles the public entry before applications and APIs, supports TLS termination at the edge, backend cloaking, health checks, and failover. This allows a cluster to not publicly expose its internal topology while the edge processes external traffic. DNS-01 automation is a component of the certificate lifecycle, not the entire edge function.

For platform teams, a clear separation emerges: DNS and certificate issuance must be automated and auditable; edge routing and protection mechanisms belong to the public entry layer; Kubernetes remains responsible for workloads and – depending on the architecture – for internal TLS processing.

Practical and Operational Scenario

A company operates multiple [Kubernetes] clusters with different providers and publishes applications under a common domain. The HTTP-01 challenge would be problematic because not every service should be publicly accessible and routing can change during a failover.

Instead, a [Kubernetes] certificate controller manages DNS-01 challenges. The ACME TXT records are published in the authoritative DNS structure. The ayedo Edge Cloud takes over Anycast DNS, public traffic entry, and optionally TLS termination. The backends remain hidden behind the edge and can be switched between clusters as needed.

The key operational gain is not just fewer manual certificate changes. DNS validation, certificate renewal, and traffic routing remain functional even when the specific [Kubernetes] location or backend changes.

FAQ

Is DNS-01 suitable for internal [Kubernetes] services?

Yes, as long as the ACME certificate authority can resolve the public TXT record. The service itself does not need to be publicly accessible via HTTP.

Can wildcard certificates be issued with DNS-01?

Yes. The DNS-01 challenge supports wildcard domains because control over the domain is proven via a TXT record.

Where should the certificate be stored?

This depends on the termination point: in the Kubernetes secret for ingress termination or in the edge layer for TLS termination at the edge.

Conclusion

ACME DNS Challenge in Kubernetes is primarily an architectural decision for an automatable certificate lifecycle. DNS-01 decouples validation from public HTTP accessibility but requires controlled DNS access, reliable propagation, and clear secret responsibilities. In conjunction with the ayedo Edge Cloud, DNS, public entry, TLS termination, and backend shielding can be organized separately from compute operations. This creates a robust foundation for cross-provider [Kubernetes] environments.