/content/en/docs/ops/configuration/traffic-management/dns/index.md...needs work?

[gswallow]

Or maybe not? Not sure. But here's my perspective, as a reader: I can't tell if this is from the perspective of outside the cluster, coming in? Or is this going out?

Additionally, there's no distinction between DNS queries and accompanying HTTP requests, in the document.

I have a difficult time comprehending what the point of the page is. Perhaps a diagram would help?

[gswallow]

For example, this paragraph:

If the client was unable to resolve the DNS request, the request would terminate before Istio receives it. This means that if a request is sent to a hostname which is known to Istio (for example, by a ServiceEntry) but not to the DNS server, the request will fail. Istio [DNS proxying](https://istio.io/latest/docs/ops/configuration/traffic-management/dns/#dns-proxying) can change this behavior.

Well of course, Istio would never receive a request. The DNS query failed, so the client -- which I assume is some developer running cURL on her laptop -- would never attempt to connect because her resolver never got an IP address (in the case of an A record query). Is that what we're talking about?

[dhawton]

The client is any client within the service mesh. So it's internal, not an external client whose traffic goes through a gateway. In this regard, the wording is still correct, because the client is still a client, and the developer running curl on a laptop is external to the mesh, so DNS requests would not generally be handled by Istio.

[gswallow]

Right, the resolver of the OS on the laptop would query its configured name server. I don't believe Istio would handle any DNS requests because it's a L4 or L7 load balancer?

I was just confused, reading this page. Not sure what it's trying to spell out.

[Aditya7880900936]

Thanks for the clarification in the thread — this helped a lot.

I think the main issue is that the document does not clearly state that it only applies to
clients running inside the mesh, and that “client” refers to a workload with a sidecar,
not an external user or laptop.

I’m planning to:

• Explicitly define the scope and client perspective at the top of the page
• Separate DNS resolution behavior from HTTP request handling
• Reword the confusing paragraph to avoid implying external DNS involvement
• Optionally add a simple diagram to show the flow

I’ll open a PR with these clarifications shortly.

[Aditya7880900936]

I’ve opened a PR that clarifies the client scope and DNS resolution behavior,
and rewords the confusing section discussed above.