Istio 1.25 connects ambient DNS identity to waypoint policy

A layer-four proxy sees a destination address and port, without the HTTP hostname that can distinguish application destinations sharing those coordinates. That becomes important when a mesh needs to recognize an external service and send its traffic through an appropriate waypoint. DNS is part of the destination-identification mechanism, rather than merely a prerequisite for establishing a connection.

The Istio 1.25 announcement on March 3 makes DNS proxying the default for ambient workloads. It also introduces policy attachment to GatewayClass, allowing authorization defaults to cover every instance of the istio-waypoint class. These changes affect different stages of the traffic path, but both address how ambient identifies and controls the destination a workload reaches.

I consider workload identity and consistent policy the reasons to accept Istio's operational cost. Ambient changes where that cost appears. A workload may no longer carry the same sidecar, but node capture, destination discovery and waypoint authorization still need to agree about the traffic they handle.

DNS supplies information ztunnel cannot read from HTTP

The announcement contrasts ordinary HTTP routing with ambient's layer-four view. Ztunnel does not inspect HTTP headers, so it cannot rely on an HTTP Host header to identify the intended service. The release specifically calls out ServiceEntry addresses and egress waypoints as cases where DNS proxying is required.

The 1.25 change notes describe two related defaults. The cni.ambient.dnsCapture value becomes true, enabling DNS capture for ambient workloads. PILOT_ENABLE_IP_AUTOALLOCATE also becomes true, enabling the newer IP auto-allocation implementation.

For ServiceEntry objects without an explicit address, the new allocation controller records addresses in status.addresses. That makes the allocated identity visible in the resource. The change notes identify allocation instability and ambient support among the problems addressed by the newer implementation.

Allocation and DNS capture remain separate operations. The presence of a status address does not establish that a workload receives that address during resolution. The proxy needs DNS capture to make use of the allocation in the intended traffic path. This is why inspecting a ServiceEntry alone does not fully describe the workload's destination view.

The notes also deprecate the older ISTIO_META_DNS_AUTO_ALLOCATE proxy metadata setting in favor of the status-based controller. Existing users may retain the older mechanism, but new adoption should use the new one. The release therefore includes a change in both defaults and the recommended implementation for allocation.

New defaults do not rewrite every running Pod

The upgrade notes explicitly limit automatic DNS capture to new Pods. Existing ambient Pods keep their current capture behavior. An upgraded installation can therefore contain workloads with different DNS paths even though they share the same mesh version and namespace enrollment.

The documented choices for existing Pods are to restart them or enable the new in-Pod iptables reconciliation feature. Reconciliation is off by default in 1.25. When enabled, a starting istio-cni Pod inspects previously enrolled Pods and updates their rules when it finds a difference.

That distinction matters when diagnosing a partial rollout. A new test Pod may demonstrate the new default while a long-running application still uses the old capture rules. Successful behavior in the new Pod does not prove that the same node-side changes reached the existing one.

Individual Pods can override the global DNS choice through ambient.istio.io/dns-capture. This fragment shows the opt-out annotation on a Pod. It is a declaration of changed capture behavior, not a general remedy for every DNS failure.

metadata:
  annotations:
    ambient.istio.io/dns-capture: "false"

The release warns that disabling capture can break features including ServiceEntries and egress waypoints. It may still be useful for a workload that interacts poorly with DNS proxies. The tradeoff is explicit because the same capture mechanism participates in destination identification for those features.

Compatibility settings also matter. The change notes say compatibilityVersion=1.24 can preserve the earlier ambient capture default. A version number alone is therefore insufficient to infer whether capture is enabled. Installation values and Pod-specific settings can deliberately select different behavior.

A policy applies at an enforcement point

The second major change concerns authorization attachment. In sidecar mode, a workload selector attaches policy to the workload's proxy. The 1.25 announcement explains that selector-targeted policy in ambient is enforced by ztunnel. Waypoints instead use Gateway API-style references to identify their policy targets.

This creates a potential indirect path. A workload can be denied direct access to an endpoint while still reaching it through a waypoint permitted to connect to that endpoint. The announcement identifies this configuration as a reason to support authorization policy defaults for waypoints themselves.

Version 1.25 adds attachment to a named GatewayClass as well as a named Gateway. Targeting the istio-waypoint class allows a policy to apply across waypoint instances. That gives administrators a common place to establish a deny baseline without enumerating every waypoint individually.

The release makes a default-deny policy available. It does not say that installing 1.25 automatically denies every waypoint request. Administrators must declare the policy and the intended exceptions. Confusing the ability to set defaults with a newly installed global denial would misrepresent the release's behavior.

The distinction also explains why a policy's selector is not merely a different spelling of a waypoint reference. Those attachment mechanisms identify different enforcement points. A correct rule at one point does not automatically cover a path that passes through another point with different permissions.

I find class-level policy useful precisely because it makes that shared responsibility explicit. An organization can state a waypoint baseline while leaving application-specific rules associated with their intended targets. The value depends on the complete path being covered, including indirect access through a permitted proxy.

Node upgrades also affect capture correctness

The release announcement separately says istio-cni can be upgraded in place without cordoning the node to prevent newly created Pods from escaping ambient capture. According to the detailed notes, new Pods are prevented from starting while the CNI agent is being restarted or upgraded. The feature is enabled by default.

This addresses a different interval from reconciliation of existing Pods. Reconciliation updates rules already present in a workload. Safe upgrade behavior handles creation while the component responsible for capture is unavailable. Both are needed to describe capture continuity, but they operate on different lifecycle events.

The change notes also clarify that DNS traffic now respects traffic-exclusion annotations for ports and IP ranges. They explicitly say this behavior began in the 1.23 series and was omitted from those release notes. It should therefore be treated as documentation of an earlier change, without presenting it as a behavior first introduced today.

That correction is relevant when examining a workload that opts out of some traffic capture. DNS can follow an exclusion that would previously have been ignored. An operator needs the actual capture rules and annotation semantics, not an assumption that DNS is always treated as an exceptional path.

The path has several independently observable decisions

For ambient egress, a workload's DNS answer, the ServiceEntry allocation and the selected waypoint are related but distinct pieces of state. Authorization then determines whether the relevant connections are permitted. Upgrading one component does not establish that every piece has changed for every existing Pod.

The release provides more explicit controls for those transitions. Status-based addresses improve visibility into allocation. Pod annotations state a local DNS override. GatewayClass attachment states a policy baseline across waypoint instances. These declarations give operators concrete objects to inspect when the intended path and the observed path differ.

Telemetry also gains context about where traffic travels. The announcement adds source and destination zone and region labels to ztunnel metrics and expands support for Kubernetes trafficDistribution across data planes. These labels do not prove an authorization decision, but they help describe a path's locality after it has been selected. Keeping locality observations separate from policy observations avoids treating a request that stayed within a zone as evidence that the intended identity restriction was enforced.

The practical result is a more coherent default ambient installation, with DNS capture enabled for newly enrolled workload Pods and a way to apply common waypoint authorization policy. Existing workloads still need their capture state understood, and policy still needs to target the component that enforces the intended boundary. Those are separate conditions for making the same application request reach its intended destination under the intended authorization rules.