istio: Istio routes to wrong headless service

Is this the right place to submit this?

• This is not a question about how to use Istio
• This is not a security vulnerability or a crashing bug

Bug Description

I have made a minimal reproduction of my problem in minikube like so. It is a fresh minikube with nothing done but istio installed

I have a service like so

apiVersion: v1
kind: Service
metadata:
  name: mys
spec: 
  clusterIP: None
  ports:
  - name: r
    port: 80
    protocol: TCP
    targetPort: 80

And an endpoints like so

apiVersion: v1
kind: Endpoints
metadata:
  name: mys
susbsets:
- addresses:
  - ip: 142.250.179.238
  ports:
  - name: r
    port: 80
    protocol: TCP

I make this service and endpoints in namespace aaaaa and namespace bbbb.

I make a pod in aaaa and bbbb, I have istio-injection enabled for both namespaces.

From each pod I curl mys. In the logs for istio-proxy in both pods, I see the same service referred to, e.g. let’s say mys.aaaa.svc.cluster.local.

But this doesn’t make any sense to me, I anticipated the pod in aaaa would use mys.aaaa.svc.cluster.local and in bbbb would use mys.bbbb.svc.cluster.local. Actually this behaviour of routing to a common place occurs even if the services themselves have different names (e.g. mys1 and mys2, a curl for mys1 will go to mys2)

This situation is unhappy for me, because I want to have destination rules in both namespaces which have a workload selector and target the service in that particular namespace. And indeed, in my actual use case, this is causing me problem, the destination rule works in the one namespace containing the common service that istio is routing to, but not any of the others.

Ultimately I can work around this, but this setup of having a service and endpoints per namespace is part of a previous design that I must conform to.

Version

istioctl
---
client version: 1.20.0
control plane version: 1.20.0
data plane version: 1.20.0 (3 proxies)

kubectl
---
Client Version: v1.26.0
Kustomize Version: v4.5.7
Server Version: v1.25.3

Additional Information

No response