`--service-type-filter=ClusterIP` + headless service with `external-dns.alpha.kubernetes.io/endpoints-type=NodeExternalIP` does not produce records

[babinin]

What happened:
When using external-dns with the --service-type-filter=ClusterIP flag, headless services annotated with external-dns.alpha.kubernetes.io/endpoints-type=NodeExternalIP do not result in any DNS records being created.

What you expected to happen:
Records should be created for headless services that are explicitly annotated with external-dns.alpha.kubernetes.io/endpoints-type=NodeExternalIP, even if --service-type-filter=ClusterIP is enabled.

How to reproduce it (as minimally and precisely as possible):

1. Deploy ExternalDNS with:

   --source=service
   --service-type-filter=ClusterIP
   --fqdn-template={{.Name}}.{{.Namespace}}.cluster.com
   

2. Create a headless service:

   apiVersion: v1
   kind: Service
   metadata:
     name: test-headless
     annotations:
       external-dns.alpha.kubernetes.io/endpoints-type: NodeExternalIP
   spec:
     clusterIP: None
     selector:
       app: my-app
     ports:
     - port: 80
       targetPort: 80

3. Observe that no DNS records are created for test-headless.default.cluster.com..

Environment:

• External-DNS version: v0.19.0
• DNS provider: google
• Kubernetes version: v1.32.2, v1.33.4

[ivankatliarchuk]

This doesn’t look like a bug, but rather expected behavior.

From the docs:

--service-type-filter=SERVICE-TYPE-FILTER
# The service types to filter by. Specify multiple times for multiple filters 
# to be applied. (optional, default: all, expected: ClusterIP, NodePort, 
# LoadBalancer or ExternalName)

This flag acts as a filter, and it behaves consistently with other filter flags in ExternalDNS. Annotations do not override filters — and shouldn’t in this case either.

To illustrate with another example:
If you run with --source=ingress, ExternalDNS will only look at Ingress objects, regardless of presence of other annotations on resource. Filters are a way of narrowing down what resources are considered in the first place.

OR more relevant examples

--annotation-filter="only-this-resourcest-to-consider" # only resources with this annotation considered regardless of other annotations presense
--target-net-filter=10.0.0.0/8 # only this CIDR is considered regardless of other annotations presence
--domain-filter=example.com  # only this domain is considered regardless of other annotations presence
--zone-id-filter=ABCDEF12345678 # only this zone id is considered regardless of other annotations presence

^ Non of these filters could be overridden by the annotation.

If you want to include NodePort or other service types, you need to configure them explicitly, for example:

--service-type-filter=ClusterIP
--service-type-filter=NodePort

Or you can remove the filter entirely to make sure all types considered. Also make sure your RBAC rules allow access to the relevant resources (e.g. nodes if needed).

[ivankatliarchuk]

The precedence isn’t clearly documented anywhere. Based on current behavior, the order seems to be:

1. Annotation
2. CLI flags, except when the flag is a filter flag — in that case, annotations are ignored
3. Defaults

So in practice:

• Annotations override most flags.
• Filter flags (--service-type-filter, --source, etc.) define the scope of resources considered, and annotations outside that scope won’t apply.
• If neither annotations nor flags specify something, defaults are used.

Might be worth clarifying this in the docs to avoid confusion.

[babinin]

The combination of the --service-type-filter=ClusterIP flag with an annotated headless service works in version 0.16.1.
But if it shouldn't work in version 0.19.0, then perhaps this should be clarified in the documentation.
Thanks!

[ivankatliarchuk]

It's hard to disagree. We should if we could. As this is an open source project, with limited resources, it's not always easy to identify when a bug fix or new feature might change existing behavior and what the effect is going to have. We try to flag these changes when/if we catch them.

[ivankatliarchuk]

I need to debug a bit more. What are the other arguments?

[babinin]

Thank you for your attention to this issue.

List of all used flags:

- --fqdn-template={{.Name}}.{{.Namespace}}.cluster.com
- --google-project=project
- --interval=5m
- --log-format=json
- --provider=google
- --registry=txt
- --service-type-filter=ClusterIP
- --source=service
- --txt-owner-id=cluster-com