v0.40.6-rc1: Transfer Layer Supports Proxy Redirect Targets

In the container image distribution chain, registries frequently redirect requests to CDNs or image acceleration nodes. When the client sits behind a forward proxy, the "resolve first, then pin the IP" transfer logic breaks down — the address resolved by local DNS may be entirely unreachable, while the only connection that actually works is the proxy-side resolution. This commit in v0.40.6-rc1 (#19065) targets exactly this scenario by adjusting the transfer layer's proxy behavior.

The Core Change: Hand DNS to the Proxy When One Exists

The first line of the commit message already spells out the policy fork: Behind a proxy, defer redirect-target DNS to the proxy; without one, keep the resolve-and-pin path.

In other words, when a request is detected as going through a proxy, the client no longer performs its own DNS resolution of the redirect target and pins the result — it hands that step off to the proxy. Without a proxy, the original "resolve and pin the IP" path remains unchanged. This fork avoids connection failures caused by a mismatch between local resolution results and the actual egress in proxy environments, while preserving the existing protection for direct-connection scenarios.

A forward proxy here refers to an intermediary service that the client actively configures to issue requests to the outside on its behalf, common in corporate intranets and CI environments. HTTP proxies establish tunnels via CONNECT, while HTTPS requests are often DNS-resolved by the proxy itself. In container image pulls, registries frequently use 302/307 redirects to point blob requests at object storage or CDNs, after which the client needs to resolve the new redirect target hostname. Whether this hop goes through a proxy and who performs the DNS directly determines whether the connection can be established. This change makes exactly that judgment — whether a proxy exists — at this point, choosing between local resolution and handing it to the proxy. It is a transport-layer policy adjustment targeting the "redirect target" rather than the "original registry address."

Why "Pinning the IP" Fails Under a Proxy

"Resolve-and-pin" is a common transport hardening technique: resolve the hostname first, then use the resulting IP consistently in subsequent connections, reducing risks such as DNS rebinding. But its premise is that the client's network egress and DNS resolution environment are consistent.

Introducing a forward proxy breaks that premise. The client's DNS server may be unable to resolve the registry's redirect target domain, or may resolve it to an intranet-unreachable address, while the resolution that actually takes effect happens on the proxy's network. Continuing to pin the locally resolved IP then amounts to pointing the request down a dead end. Returning resolution authority to the proxy is the sensible way to realign the two.

DNS rebinding is an attack against the network resolution layer: an attacker controls a domain whose extremely short TTL lets its DNS records return different IPs between two resolutions — the first passing validation with a legitimate address, the second pointing at an intranet or malicious address — thereby bypassing hostname-based access restrictions. "Resolve and pin the IP" is precisely the defense born to suppress this class of attack: once an IP is resolved it is hard-coded into the connection with no further re-resolution, robbing the attacker of the window to switch targets. The cost is that the connection is bound to one specific IP, so any environmental change that makes that IP unreachable (for example, a different egress network, or resolution results that vary by network location) causes the connection to fail outright. Thus in proxy scenarios, handing the entire resolution step to the proxy is essentially trading "trusting the proxy-side resolution environment" for "connection reachability," while the proxy typically performs its own caching and validation — so rebinding risk is not entirely abandoned.

Trust Handling for Default registry / CDN Hostnames

The change also touches hostname trust logic: Trust default-registry/CDN hostnames with no local DNS.

For default registries and known CDN hostnames, when local resolution fails, they are now trusted directly rather than aborting the flow because resolution failed. Taken together with the previous point, this effectively tightens the pin policy for direct-connection scenarios while relaxing it for proxy and known-trusted-hostname scenarios, ensuring a usable transfer path under different network topologies.

Container registry and CDN hostnames form a relatively fixed, infrastructure-controlled trusted set — for example, Docker Hub and common cloud providers' image acceleration domains. The traditional approach relies on a preset trusted hostname list, but when local DNS cannot resolve these names (intranet DNS lacking external recursion, or domains blocked by local policy), strict validation would deem them untrusted and abort the pull. Allowing "trust even when local resolution fails" shifts the basis of the trust decision from "can it be resolved" to "is the hostname on the whitelist." This avoids false rejections caused by a missing DNS environment, but also means the trust boundary relies more on the accuracy of whitelist maintenance rather than runtime resolution evidence.

A nil CancelFunc Crash Fixed Along the Way

Beyond the proxy-related changes, the commit also fixes a null-pointer crash in blobDownload.release: a nil CancelFunc was being called on the release path. Blob download is a critical step in pulling image layers, and such crashes tend to occur on cancellation or error-cleanup paths with relatively obscure reproduction conditions — a typical boundary bug fix.

Who Should Care About This Release

If you pull images in CI environments, corporate intranets, or any scenario that forces traffic through a forward proxy, this change directly affects whether redirect targets can be reached. For purely direct-connection environments, transfer behavior is largely unchanged, but you still benefit from the nil CancelFunc crash fix. As an rc version, it's advisable to first validate image pulls under your proxy configuration on a test pipeline before rolling it out to production.

One-line Summary

v0.40.6-rc1 allows redirect-target DNS to be resolved by the proxy in proxy scenarios and fixes a nil CancelFunc crash.

Paragraph Summary

Commit #19065 in v0.40.6-rc1 adjusts transfer-layer behavior for proxy scenarios in container image distribution. The core change: when a request passes through a forward proxy, DNS resolution of registry redirect targets (such as CDNs or image acceleration nodes) is no longer done locally by the client and pinned to an IP — it is handed to the proxy; without a proxy, the original "resolve and pin the IP" path is preserved. This resolves connection failures caused by a mismatch between local resolution and the actual network egress under a proxy. The change also relaxes trust for default registry and known CDN hostnames: they are trusted directly when local DNS cannot resolve them. Additionally, it fixes a crash caused by calling a nil CancelFunc in blobDownload.release. Transfer behavior in purely direct-connection environments is largely unchanged, but still benefits from the crash fix.