feat(source): add ACME DNS-01 delegation CNAME wrapper

[norman-zon]

What does it do ?

Adds an opt-in source wrapper that generates ACME DNS-01 delegation CNAME records for every hostname discovered from sources. When enabled, each A/AAAA/CNAME endpoint (e.g. from Ingress, Service, or Gateway API routes) additionally gets a managed record:

_acme-challenge.<hostname> CNAME <rendered template>

New flags:

• --acme-cname-delegation-target-template — Go template for the CNAME target (e.g. {{ .HostnameWithoutWildcard }}.acme.example.net); setting it enables the feature, following the same pattern as --nat64-networks
• --acme-cname-delegation-domain-filter — restrict generation to matching domain suffixes (repeatable)
• --acme-cname-delegation-ttl — TTL for the generated CNAMEs; falls back to --min-ttl / provider default

Behaviour:

• exactly one delegation CNAME per hostname (A+AAAA and wildcard+apex deduplication)
• wildcard hostnames map to the challenge name without the wildcard label (*.app.example.com → _acme-challenge.app.example.com), matchinghow ACME validates wildcard certificates
• explicitly defined _acme-challenge.* endpoints (e.g. via DNSEndpoint) always take precedence — the wrapper never generates a record for achallenge name a source already provides
• the resource label and object references are carried over from the originating endpoint; ownership TXT records are handled by the TXT registry as usual
• startup validation: CNAME must be in --managed-record-types, the domain-filter/TTL flags require the template flag, and a warning is logged when combined with --regex-domain-filter (the regex must also match the generated names)

Implemented as a source wrapper in source/wrappers/ (modeled on the PTR and NAT64 wrappers), placed before the post-processor so --min-ttl applies to the generated records. The target template reuses the shared template function set from --fqdn-template via a new exported template.Parse helper.

Testing: unit tests for the wrapper (wildcard, dedup, domain filter, TTL, precedence, template failure modes, error propagation), the wrapperwiring, flag parsing, and validation; the kind-based e2e script now also enables the feature and verifies the delegation CNAME resolves via CoreDNS.

Deliberately deferred as follow-ups to keep this PR reviewable: per-resource annotation opt-in/out (needs ProviderSpecific plumbing through sources like the PTR record-type mechanism) and restricting generation by source type.

Fixes #6535

Motivation

Many organizations use cert-manager with DNS-01 challenges but do not want the ACME client to have write access to production application zones. The established pattern (delegated domains for DNS-01) is to CNAME the challenge name into a dedicated zone that the ACME client may write to, so its credentials are scoped to e.g. acme.example.net instead of example.com.

ExternalDNS already discovers every hostname that needs regular DNS records, so it is in the right position to create the matching delegationCNAMEs — the alternatives (Terraform for dynamic hostnames, a DNSEndpoint per application, or a custom controller/Kyverno policy) either don't scale for self-service Ingress/HTTPRoute hostnames or duplicate logic ExternalDNS already has. See #6535 for the full discussion.

The feature is strictly opt-in and does not change existing record generation by default.

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign vflaux for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

Welcome @norman-zon!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[kubernetes-prow]

Hi @norman-zon. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[linux-foundation-easycla]

• ❌ - login: @norman-zon / name: Norman Stetter. The commit (f261dce) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

[norman-zon]

/easycla