[Feedback] Service Entry: DNS resolution or None

[sindhuraperi26]

Describe scenario
Subject: Issue with Service Entry Resolution Istio Add-on
Question
We are currently experiencing an issue with our Istio add-on in AKS version 1.30 and Istio version 1.23 as per the attached documentation recommendations.
When we toggle the service entry resolution to NONE, we encounter a problem where DNS is not resolved, resulting in a "no healthy upstream" error (503). However, when we change it back to DNS, the request returns successfully with a status code of 200.
We need guidance on how to achieve performance optimization as suggested by Microsoft in the documentation while resolving this issue.
Are there any additional changes required apart from just toggling the service entry resolution like IP address mapping in the service entry/route table? Or is this a known issue?

[https://learn.microsoft.com/en-us/azure/aks/istio-scale](Service Entry- Performance)

[nshankar13]

@sindhuraperi26 from my understanding, NONE should work provided that the upstream DNS service (coreDNS / kubeDNS) resolves the hostname prior to the request getting intercepted by Envoy. Could you try testing via an ephemeral container in your application Pod to ensure that DNS resolution works as expected?

Directly adding the addresses to the SE could work but shouldn't be required. If it's not a problem with the upstream DNS request, can you share the full Service Entry, Virtual Service, and DestinationRule to take a closer look?

Here is a related issue for ServiceEntry with resolution: NONE and TLS origination, which may be relevant: istio/istio#49450.

In terms of performance optimization and avoiding coreDNS overload, would also suggest looking into the DNS proxying feature, which avoids a duplicate call to coreDNS by intercepting the DNS request via Envoy. https://istio.io/latest/docs/ops/configuration/traffic-management/dns-proxy/.

[sindhuraperi26]

@nshankar13 Sure, attaching the Service Entry, Virtual Service and Destination Rule used

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: test-external
namespace: aks-istio-ingress
spec:
exportTo:
- "."
hosts:
- "test.external.com"
location: MESH_EXTERNAL # Fixed as its mesh external and will be used for egress
ports:
- name: https
number: 443 # Fixed as its https port
protocol: HTTPS
resolution: NONE

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: test-external
namespace: aks-istio-ingress
spec:
exportTo:
- "."
host: test.external.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
credentialName: egress-cert
mode: MUTUAL
sni: test.external.com

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: external-through-egress
namespace: aks-istio-ingress
spec:
exportTo:
- "."
hosts:
- test.external.com
gateways:
- external-egress
http:
- match:
- gateways:
- external-egress
port: 443
route:
- destination:
host: test.external.com
port:
number: 443
weight: 100

there is another set of Virtual Service and Destination Rule at the workload (namespace level) which routes to the above set of policies. Also, we are using the ingress gateway internal as Egress for the outbound connection in the interim till Egress is available in add-on
Note: Resolution NONE gives unhealthy upstream and Resolution DNS works here