fix(source): filter provider-specific properties to configured provider

[ivankatliarchuk]

What does it do ?

• Add method on *Endpoint in endpoint/endpoint.go — to retains only properties whose name is prefixed with / (e.g. aws/evaluate-target-health when provider is aws), drops the rest, and sorts the result by name for deterministic output. This should reduce frictions when records created then recreated and etc
• Wire the filter into postProcessor.Endpoints in source/wrappers/post_processor.go — called per endpoint when a provider is configured

As part of this pr, found Cloudflare special case that is architecturally fragile (it's going to be difficult to just fix the provider in this PR)

endpoint/endpoint.go hardcodes provider == "cloudflare" in a method on *Endpoint, which is the core domain model. This couples the domain layer to a specific provider's naming quirk. Worse: when provider is cloudflare, all properties are retained including aws/evaluate-target-health...

Follow-up PR

• add integration test when merged chore(tests): Add YAML-driven integration test framework for sources #6158
• address cloudflare quirk. The real fix should be in source/annotations/provider_specific.go — cloudflare annotations should be normalized to cloudflare/proxied, cloudflare/tags, etc. during ingestion.

Motivation

When endpoints carry provider-specific properties from multiple providers (e.g., both aws/evaluate-target-health and coredns/group), all of them were passed downstream regardless of which provider was actually configured. This means a provider receives properties that belong to a different provider, which can cause unexpected behaviour or misconfiguration during record synchronisation.

Fixes #6217
Fixes #4951
Relates #4347
Relates #5947

More

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

┌──────────┬───────┐
│ Category │ Lines │
├──────────┼───────┤
│ Non-test │ +47   │
├──────────┼───────┤
│ Test     │ +309  │
├──────────┼───────┤
│ Docs     │ +21   │
├──────────┼───────┤
│ Ratio    │ 1:6.5 │
└──────────┴───────┘

Current

With the fix -> the problem gone

Fixtures

go run main.go \
    --provider=aws \
    --registry=txt \
    --source=service \
    --interval=30s \
    --dry-run \
    --fqdn-template='{{ .Name }}.example.com' \
    --label-filter='app=my-app'

---
apiVersion: v1
kind: Service
metadata:
  name: test-headless
  labels:
    app: my-app
  annotations:
    external-dns.alpha.kubernetes.io/aws-evaluate-target-health: "true"
    external-dns.alpha.kubernetes.io/coredns-group: "my-group"
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
      annotations:
        external-dns.alpha.kubernetes.io/aws-evaluate-target-health: "true"
        external-dns.alpha.kubernetes.io/coredns-group: "my-group"
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80

[coveralls]

Pull Request Test Coverage Report for Build 23116432762

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 88 unchanged lines in 5 files lost coverage.
• Overall coverage increased (+0.02%) to 79.692%

---

Files with Coverage Reduction	New Missed Lines	%
execute.go	1	59.82%
wrappers/post_processor.go	2	95.83%
wrappers/types.go	7	88.24%
endpoint.go	38	88.3%
store.go	40	49.71%

Totals
Change from base Build 23098157121:	0.02%
Covered Lines:	16627
Relevant Lines:	20864

---

💛 - Coveralls

[vflaux]

I don't think this will works with cloudflare. In endpoint.ProviderSpecificAnnotations(), other providers cut their annotation prefix (external-dns.alpha.kubernetes.io/provider-xxx) before adding a specific provider entry on the endpoint. Cloudflare keep it so the provider specifics are external-dns.alpha.kubernetes.io/cloudflare-xxx, not cloudflare-xxx. With this implementation those specifics will be filtered.
It could be tempting to simply change this and align with other providers, but we'd have to keep compatibility with DNSEndpoints that set those provider specifics.

[vflaux]

Wouldn't it be better to let each provider handle its own filtering logic? Isn’t AdjustEndpoints() already meant for that?

[ivankatliarchuk]

Btw, thank for flagging. Indeed, cloudflare is very different to other providers. I have a PR #6158 to start capturing end-2-end behaviour, it may help a bit soon.

Tested with fixtures

go run main.go \
    --provider=inmemory \
    --registry=txt \
    --source=service \
    --interval=30s \
    --dry-run \
    --fqdn-template='{{ .Name }}.example.com' \
    --label-filter='app=my-app' \
    --min-ttl=60s

---
apiVersion: v1
kind: Service
metadata:
  name: test-headless
  labels:
    app: my-app
  annotations:
    external-dns.alpha.kubernetes.io/aws-evaluate-target-health: "true"
    external-dns.alpha.kubernetes.io/coredns-group: "my-group"
    external-dns.alpha.kubernetes.io/cloudflare-custom-hostname: "true"
    external-dns.alpha.kubernetes.io/cloudflare-tags: "env:prod,team:my-team"
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80

[ivankatliarchuk]

I've added a bypass/exception for cloudflare. No plans solving cloudflare diff in this pr

Wouldn't it be better to let each provider handle its own filtering logic? Isn’t AdjustEndpoints() already meant for that?

All providers should be consistent where possible to reduce drift.

This is potential benefits of consistent providers

• Fewer spurious updates: Consistent normalization prevents unnecessary changes when only representation differs (e.g., default values added vs omitted).
• Predictable behavior: Users can rely on the same property handling across providers, reducing surprises.
• Easier testing: Common patterns allow shared test utilities and clearer expectations.
• Simplified maintenance: providers can follow established patterns; reviewers spend less time re-learning per-provider logic. Contributors understand one set of rules rather than per-provider quirks.

[ivankatliarchuk]

I've added test, that should fail, if someone is going to add a new provider with properties and support of other format.

At the moment, short syntax

• coredns
• aws
• webhook
• provider agnostic

Full syntax

• cloudflare

[ivankatliarchuk]

/test pull-external-dns-unit-test

[ivankatliarchuk]

Hi @vflaux when you around, pls have, let'f finish this review.

[vflaux]

No sure about this change. This option with enable=false will do nothing. And is that related to this PR?

[ivankatliarchuk]

Yeah, will roll it back. Basically cfg.preferAlias is false be default, so the assigment only make sense when value is true

[ivankatliarchuk]

rolled back

[vflaux]

/lgtm

[ivankatliarchuk]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ivankatliarchuk

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [ivankatliarchuk]

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