Istio 1.8 brings DNS resolution into the sidecar agent

A proxy can know how to reach a Kubernetes service while the application beside it cannot resolve the service's name. That mismatch has complicated VM participation in Istio. An application needs an address before it opens a connection, so traffic-routing configuration alone cannot complete the integration. Istio 1.8 addresses the naming step with a DNS proxy in the sidecar agent.

The November 19 release announcement presents smart DNS proxying alongside easier VM installation and automatic WorkloadEntry registration. It also adds alpha Helm 3 installation and upgrade support. These changes reduce manual work around an existing mesh, but they have different defaults and maturity levels that need to remain explicit.

I find the DNS change useful because it addresses an actual dependency of application communication. Giving a workload an identity and a configured proxy does not complete service discovery when the application cannot resolve the name it uses. The agent now participates in that earlier step, using information the control plane already has.

DNS can fail before the proxy receives traffic

Shriram Rajagopalan's November 12 design explanation describes VMs that have no access to the Kubernetes DNS server. Exposing that server outside the cluster would require additional configuration and carries security concerns. The proposed solution is to answer mesh service queries locally instead of making the VM depend directly on cluster DNS access.

The same problem appears across clusters. A service name known in one cluster may not resolve in another without additional stub services or other naming arrangements. The sidecar's knowledge of mesh services does not automatically become the application's DNS view. The new agent behavior joins those two parts of discovery.

Istiod pushes hostname-to-address mappings based on Kubernetes Services and ServiceEntries the application may access. The agent intercepts DNS queries and answers mesh service lookups from that information. Other queries go to the upstream nameservers in /etc/resolv.conf. This preserves a path for names outside the mesh without requiring Istiod to become authoritative for every domain.

The design puts the DNS implementation in the Go sidecar agent. Its authors evaluated Envoy's DNS proxy and decided it did not meet their requirements. The resulting implementation uses the agent as the local DNS participant while Envoy continues to perform traffic forwarding.

DNS results can distinguish TCP destinations

The design article also describes two external TCP services sharing a port without unique virtual IPs. Its example uses separate database hostnames on port 3306. If both map into one wildcard-address listener, the proxy lacks a distinct destination identifier to tell which configured service the application intended.

This differs from an HTTP route whose request carries a host value the proxy can inspect. The TCP example depends on destination addressing to distinguish services. The article describes forwarding to the original destination with resolution: NONE as an earlier workaround, at the cost of broader traffic handling on that port.

Smart DNS proxying allows Istio to allocate non-routable virtual IPs for eligible external services and return those addresses to the application. Envoy can then distinguish the resulting destinations and forward each to the correct target. DNS participation supplies a service-specific address at the moment the application chooses its connection destination.

The article limits this automatic allocation to services without wildcard hostnames. A wildcard external service does not receive the same solution, and the authors retain NONE resolution as the approach for that case. The distinction prevents a general claim that DNS capture removes every ambiguity in arbitrary external TCP traffic.

This also explains why an answer from the DNS proxy is part of routing behavior. The returned virtual address need not itself be an ordinary externally routable endpoint. It identifies a service to the local proxy, which has the configuration needed to make the actual upstream connection. The address and the forwarding implementation have to be understood together.

Search-path handling reduces repeated lookups

The design describes an optimization for Kubernetes search paths. Its example assumes ndots:5 and five search namespaces. A lookup for a service hostname can try each search suffix before the unsuffixed name, with A and AAAA queries for each attempt. Under those stated assumptions, the article counts twelve queries.

The agent recognizes the real service hostname within the first query and returns a CNAME plus the corresponding address records. In that example, the application can use the first response and the query count drops to two. These numbers describe the article's specific resolver scenario. They are not a universal measurement for every operating system or resolver configuration.

The mechanism still explains a broader benefit. Local knowledge of mesh names can avoid repeated unsuccessful searches against cluster DNS. The benefit comes from answering the application's actual resolver behavior, including search-path expansion, rather than only caching an exact fully qualified name after it has finally been queried.

Defaults depend on how the workload is installed

The design article says smart DNS proxying is enabled in the 1.8 preview profile. The release change notes separately say DNS capture is enabled by default for VMs installed through istioctl x workload entry configure. Those are more precise statements than saying that all existing pods receive DNS capture automatically after an upgrade.

The installation path is therefore part of interpreting the feature. The release introduces a local DNS mechanism and provides configurations that enable it. An existing workload's behavior depends on the configuration under which its agent starts. Its name-resolution result should not be inferred solely from the control plane's new version.

VM auto-registration addresses another setup task. The release lets an operator identify the workload kind to the agent and have WorkloadEntry objects created as the VM joins the mesh. That avoids maintaining each registration entirely by hand. It complements DNS resolution without performing the same function, because registration describes the joining workload while DNS serves names to its application.

Helm support returns through a new installation path

Istio 1.8 adds Helm 3 support for users whose wider deployment workflow already uses Helm. The announcement includes in-place upgrades and canary control plane deployments after installing 1.8 or later. It marks this support alpha, so its presence should not be confused with an unchanged continuation of the legacy charts removed earlier.

The release retains istioctl install and the operator as other methods. These choices expose different ways to manage the installation, while the release's new profiles can encode platform-specific settings. The point is to fit existing deployment workflows without implying that every method has the same maturity or migration path.

My preference is to distinguish installation convenience from the runtime property being sought. Helm support can make Istio fit a deployment system. DNS capture can make a VM application's service names resolvable. A successful installation does not, by itself, prove that a particular workload has the DNS configuration or connectivity it needs.

Certificate distribution reduces gateway permissions

The release moves gateway certificate reading to istiod. Gateways receive certificates from the control plane instead of reading them directly from Kubernetes. The announcement describes this as a reduction in gateway privileges, particularly relevant to gateways exposed publicly. The change notes say the new mechanism is compatible with the old arrangement and requires no cluster changes.

An experimental external CA integration uses the Kubernetes CSR API. Istiod acts as a registration authority that authenticates and authorizes the workload, then creates, approves, and watches the certificate request. Another tool supplies the signer and backend CA integration. This separates workload admission to the certificate process from the actual signing implementation.

That mechanism remains experimental in the announcement. It should not be conflated with the gateway distribution change, which concerns how gateways receive existing certificate material. Each addresses a different stage in the identity lifecycle, with its own component responsibilities.

Removed components require their own migration

Mixer is removed in 1.8, completing the deprecation described in earlier releases. Installation of third-party telemetry add-ons through istioctl is also removed. The change notes state that those applications now need separate installation and that this does not remove Istio's ability to produce their telemetry.

These removals matter to deployments carrying older integrations, even when their immediate interest is VM discovery. The mesh's new local DNS knowledge does not replace a Mixer adapter or install a monitoring backend. The release's operational changes need to be matched to the components a deployment actually uses.

For the new DNS mechanism, the concrete improvement is that an application can receive a mesh service address locally before opening its connection. Istiod supplies the service information, the agent answers or forwards the query, and Envoy interprets eligible virtual destinations using its routing configuration. That sequence explains how VM service discovery can work without exposing the cluster DNS server to the VM.