SSRF follow-up: pin the socket to the validated IP (DNS rebinding / TOCTOU)

[KnockOutEZ]

Follow-up to #206. That issue closes the static-record bypass with a resolve-and-validate re-check at every fetch seam. This one tracks the remaining TOCTOU gap: pinning the socket to the IP we already validated.

The gap: even after we resolve a host and validate every returned IP, the real connection resolves DNS again at connect time. An attacker who controls the authoritative resolver can return a public IP for the check and flip to 169.254.169.254 or an RFC-1918 host for the connect, inside the TTL window. That is classic DNS rebinding. The only airtight fix is to make the socket connect to the exact IP we validated instead of re-resolving.

Feasibility is uneven across our fetch tiers, which is why this is a separate, phased issue rather than part of #206:

1. HTTP client tier. Pinnable cleanly with a lookup/connect hook on the dispatcher, so the socket uses the validated IP and never re-resolves. Highest value, do this first.
2. TLS-impersonation tier. Depends on whether that stack exposes a connect or lookup hook. If it does, mirror the HTTP-tier approach; if not, record the residual.
3. Browser tier. Effectively unpinnable, since the browser does its own DNS and we don't control its socket layer. Options are pre-nav resolve-and-validate (check only, does not close rebinding) or routing through a local validating proxy. Whatever we pick, document the residual honestly rather than implying the browser tier is rebinding-safe.

Scope: pin the HTTP client tier first (small, high value), then the TLS tier if its stack allows, then decide the browser tier (proxy vs documented residual). The resolved-IP re-check from #206 stays as the floor everywhere, so even the unpinned tiers still block the static-record case.

Depends on #206 landing first, since the re-check is what produces the validated-IP set to pin to.

@spartan8806 flagging you, since you called this out in #206 and offered to take the pinning follow-up. No pressure to own it, but it's yours if you want it. Same phasing applies: HTTP tier first.

[spartan8806]

Thanks for writing this up so precisely — happy to take it. #206 is up as #210, so the
validated-IP floor is in place across every seam; the pinning work builds directly on that set.

Agreeing with your phasing, with a concrete plan:

1. HTTP client tier (first). Node's fetch is undici underneath, so this is pinnable
atomically: resolve + validate once, then run the real connect through a per-request
undici.Agent whose connect.lookup hands back only the IP(s) we just validated — no
second resolution, so there's no TTL window left to flip. Keep the TLS servername and the
Host header set to the original hostname, so SNI, certificate verification, and vhost
routing all still work against the name while the socket lands on the pinned IP. Each redirect
hop repeats resolve → validate → pin on its own target. That collapses the check and the
connect into one step and genuinely closes rebinding on this tier.

2. TLS-impersonation tier. Gated on whether that stack exposes a connect/lookup hook the
way undici does. I'll dig in — if it does, I mirror the HTTP approach; if it doesn't, I'll
record the residual honestly rather than imply it's closed. The #206 re-check stays as the
floor there regardless.

3. Browser tier. Agreed it's effectively unpinnable — Chromium owns its own resolver and
socket. #210 already lands the pre-nav resolve-and-validate as check-only, with a comment
saying in as many words that it does not close rebinding and pointing at this issue, so the
residual is documented rather than papered over. A local validating proxy is the only real
close, but it's a heavier piece of infra — I'd rather weigh that as its own decision after the
HTTP tier is done than bundle it in.

Net: HTTP tier first (real close), TLS tier if the stack allows (else documented residual),
browser tier stays check-only + honest until we decide the proxy is worth it. Floor from #206
stays everywhere. I'll start on the HTTP-tier pin once #210 lands, since that's what produces
the validated set to pin to.