CONCEPT Cited by 1 source
DNS rebinding SSRF risk¶
What it is¶
DNS rebinding (as an SSRF risk) is the structural observation that the IP address a hostname resolves to at validation time is not guaranteed to be the same IP it resolves to at request-send time. An attacker who controls the authoritative DNS for a hostname can change the answer between the two moments — validation sees a public IP and passes; send resolves the now-updated record and reaches a private IP.
It is the time-of-check-to-time-of-use (TOCTOU) race specialised to DNS. The application's URL validation is not atomic with the underlying HTTP request; DNS is the mutable state sitting between them.
Why it defeats URL validation alone¶
The standard URL- validation suite — HTTPS required, private-IP blocklist, own-domain blocklist, even post-DNS-resolution re-check — all execute at submission time, against the DNS state of that moment. An attacker's authoritative DNS can:
- Return
203.0.113.10(public, legitimate-looking) at validation time so the URL passes checks. - Return
10.0.0.1(internal) at send time so the actual HTTP request lands inside the victim's VPC.
TTL is the tuning knob: the attacker sets a very low TTL (1 second) on the authoritative record so the re-resolve between check and send picks up the new answer. Stub resolvers + OS caching mitigate partially but are not guaranteed.
Canonical verbatim framing from sources/2026-04-21-planetscale-webhook-security-a-hands-on-guide: "Remember, the user can always update the host's DNS after this check has passed. This alone is not enough to protect from SSRFs."
The structural implication¶
Because validation-time state and send-time state are not coupled, defense cannot live only at submission time. The send-time defence must re-enforce the same rules against the actual IP the HTTP request connects to, after DNS has been re-resolved for the outbound request.
This is the architectural reason webhook-sender services deploy an isolated egress-proxy tier (e.g. Envoy) that sees the resolved IP of each outbound request and blocks it if private / loopback. Egress proxy + URL validation together defeat DNS rebinding because both moments of enforcement are covered — the attacker cannot simultaneously show a public IP at validation time AND at send time.
Mitigations enumerated¶
- Egress-proxy tier re-enforcement. Canonical (patterns/isolated-egress-proxy-for-user-urls).
- Resolve-then-connect-by-IP. Application resolves
hostname itself, verifies IP, connects to that literal
IP (not the hostname) with
Host:header set. Defeats any subsequent DNS change because the connection target is pinned. Brittle with TLS SNI + cert-name validation; requires careful library support. - Network-level egress rules. Firewall / VPC egress rules that structurally block internal ranges regardless of what the application does. Out-of-band of both DNS and application logic.
- Pinned DNS with minimum TTL. DNS resolvers that enforce a minimum TTL (e.g. 60s) reduce the rebinding window but don't eliminate it.
None of these are complete on their own; the composition is defense in depth.
Seen in¶
- sources/2026-04-21-planetscale-webhook-security-a-hands-on-guide — Canonical wiki disclosure of DNS rebinding as the structural reason URL validation is insufficient for webhook-sender SSRF defence (2023-11-21, Mike Coutermarsh, re-fetched 2026-04-21). Framed as the one-sentence load-bearing caveat after the four-check URL-validation suite: "Remember, the user can always update the host's DNS after this check has passed. This alone is not enough to protect from SSRFs." Motivates the Envoy-based egress proxy as the send-time re- enforcement layer that closes the gap.