Kubernetes DnsSrv service discovery across namespace

Preamble:
In kubernetes we can communicate between services according to the [DNS name](https://kubernetes.io/docs/concepts/services-networking/service/#dns) and [(specification)](https://github.com/kubernetes/dns/blob/master/docs/specification.md).
With service discovery named endpoints in Aspire we can use the "http://_{endpointName}.{serviceName}" uri in order to work, awesome!
So in production within a kubernetes cluster, in which we have namespaces, I thought it was normal to add the namespace after the service name, in case of communication between services of two different namespaces, as described in the kubernetes service dns concepts.
Unfortunately the service discovery works only between services of the same namespace and without declaring anything after the service name.
So I though it was an issue with our services configuration but after follow the [debug instruction for CoreDNS](https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution) I have not found any sort of issue.

Issue:
HttpClient with service discovery enabled which make request to named endpoint of a service which belong to a different namespace returns always `The endpoint collection contains no endpoints`.
After debugging service discovery implementation I found that the srv query made contains the current namespace instead of the provided one within the service name (e.g. with `http://_grpc.service-name.default`).
The namespace is returned from the `DnsSrvServiceEndPointResolverProvider.ReadQualifiedNamespaceFromResolvConf` method which return the second result of the `search` line split by space (e.g. `search test.svc.cluster.local svc.cluster.local cluster.local` return `test.svc.cluster.local`) which is then appended to the srv query which result in `http://_grpc._tcp.service-name.default.test.svc.cluster.local`.

Workaround:
We can use the `QuerySuffix` option to hard code `svc.cluster.local` which is then appended to the srv query instead of using the `DnsSrvServiceEndPointResolverProvider.ReadQualifiedNamespaceFromResolvConf` method, which result in `http://_grpc._tcp.service-name.default.svc.cluster.local` which works perfectly.

Suggestion;
It might be good to avoid query suffix and instead take the third value of the `search` line split operation within `DnsSrvServiceEndPointResolverProvider.ReadQualifiedNamespaceFromResolvConf` in case of namespace already declared in serviceName parameter.