Posted on
3 minutes
498 words

Simplifying DNS01 Challenges with webhook-dnsendpoint

If you’re working with Kubernetes and cert-manager, you know that obtaining TLS certificates automatically is essential for securing your applications. One of the most powerful ways to validate domain ownership for certificate issuance is through DNS01 challenges. I present to you my project that bridges cert-manager with the DNSEndpoint CRD: webhook-dnsendpoint.

Note: This blogpost was written with the help of AI.

What is webhook-dnsendpoint?

The webhook-dnsendpoint project is a custom webhook solver for cert-manager that brings support for the DNSEndpoint Custom Resource Definition (CRD). This integration allows cert-manager to leverage DNSEndpoint resources when solving ACME DNS01 challenges, providing a Kubernetes-native approach to DNS management during the certificate issuance process.

The Problem It Solves

When using cert-manager with the ACME protocol (like Let’s Encrypt), you need to prove domain ownership. The DNS01 challenge method requires you to create specific TXT records in your DNS zone. Traditionally this means:

  • Integrating directly with your DNS provider’s API
  • Managing provider-specific credentials
  • Dealing with various DNS provider limitations
  • All the problems that can arise due to faulty network, synchronisation and so on

The webhook-dnsendpoint project offers an alternative approach by utilizing the DNSEndpoint CRD, which provides a standardized, Kubernetes-native way to manage DNS records.

How It Works

The webhook-dnsendpoint acts as a bridge between cert-manager and any system that implements the DNSEndpoint CRD with TXT record support. Here’s the flow:

  1. cert-manager initiates a DNS01 challenge for certificate validation
  2. The webhook-dnsendpoint solver creates a DNSEndpoint resource with the required TXT record
  3. A DNS controller (like k8s-gateway) watches for DNSEndpoint resources and publishes them
  4. The ACME server validates the DNS record
  5. The certificate is issued

Key Requirements

To use webhook-dnsendpoint, you’ll need:

  • cert-manager installed in your cluster
  • DNSEndpoint CRD with TXT record support
  • A DNS controller that can serve DNSEndpoints (the project uses k8s-gateway for testing)

Testing Approach

Rather than using the official cert-manager webhook test suite, I had to implements integration tests through a bash script. The reason ? The official test suite didn’t support the separate setup function needed to wait for the k8s-gateway pod to spin up and start serving DNS records.

Why This Matters

The webhook-dnsendpoint project is particularly valuable for organizations that:

  • Already use DNSEndpoint CRDs in their infrastructure
  • Want a more Kubernetes-native approach to DNS management
  • Prefer declarative DNS configuration over provider-specific API integrations
  • Use controllers like k8s-gateway for internal DNS management

Getting Started

If you’re interested in trying webhook-dnsendpoint, check out my GitHub repository. The project includes integration tests that show how to set up and use the webhook with k8s-gateway.

For detailed instructions on running the tests, refer to the tests README in the repository, which walks you through the integration test setup.

Conclusion

Whether you’re looking to simplify your cert-manager setup or want to integrate with existing DNSEndpoint infrastructure, my project is worth exploring as part of your Kubernetes certificate management strategy.

And of course, if you need support I am here (I like icecream scoops but also money as payment).

Share