fix(source): scope CNAME conflict warnings to the configured domain filter

[jojinkb]

What does it do ?

Stops the Only one CNAME per name warning from firing for DNS names that are outside the configured --domain-filter (and related --exclude-domains / --regex-domain-filter / --regex-domain-exclusion flags), while keeping the exact same warn-level message for names this instance actually manages.

Since #6174, sources call endpoint.MergeEndpoints(), which emitted the warning before the planner applies the domain filter — so hosts that exist purely for in-cluster routing (Istio Gateways/VirtualServices, Ingress hosts used by a CDN, ...) produced a misleading warning every sync interval even though ExternalDNS will never manage them.

Following the reviewer guidance on #6551 (fix it generically for all sources, gate the warning instead of pre-filtering endpoints, and use the source-wrapper pattern like nat64source), this PR:

• adds a new CNAMEConflictSource wrapper (source/wrappers/cnameconflictsource.go) installed at the end of the standard wrapper pipeline. It detects CNAME endpoints sharing the same DNS name + set identifier with different targets and warns only when the name matches the domain filter; out-of-scope conflicts are logged at debug level. Endpoints are returned unmodified — conflicting records are still resolved by the planner's conflict resolver, exactly as before.
• demotes the merge-time log in endpoint.MergeEndpoints() to debug level (same message text, still useful to trace which source produced a conflict). Because the wrapper runs on the combined output of all sources, conflicts across sources (e.g. istio-gateway vs istio-virtualservice, the exact repro in the issue) are now detected too, which the per-source merge could miss.
• builds the DomainFilter once in source.NewSourceConfig() and shares it between the wrapper pipeline and the provider (controller/execute.go previously constructed it separately).

Behavior summary:

Scenario	Before	After
CNAME conflict, name matches domain filter	warn (per source)	warn (combined sources, same message)
CNAME conflict, name outside domain filter	warn	debug
No domain filter configured	warn	warn
Conflict across two sources	not detected	warn/debug per filter

Fixes #6529

Motivation

Users running --source=istio-gateway --source=istio-virtualservice (or plain Ingress, see the issue comments) with a --domain-filter get warnings every minute about "invalid DNS" for hosts that are intentionally not managed by ExternalDNS. The warning is legitimate signal for in-scope conflicts — per the maintainer feedback on #6551 it must not simply be hidden — but for out-of-scope names it is pure noise that looks like a real DNS problem.

Previous attempts #6546 and #6551 were closed after review feedback; this implements the design suggested there: keep the warning, gate it by the domain filter, apply it once for all sources via a wrapper.

Note on scope: the warning is gated by the --domain-filter family of flags only. Provider zone filters (e.g. --zone-id-filter) are not consulted, because zones are only known to the provider at plan time; if reviewers prefer gating on the registry/provider filter as well, the detection could instead move to plan.Calculate() — happy to adjust.

More

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

This change was developed with AI assistance (Claude Code); I have reviewed and tested it.

[kubernetes-prow]

Welcome @jojinkb!

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 @jojinkb. 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.

[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 mloiseleur 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