A service receives a URL, resolves its hostname, confirms that the returned address is public, and approves the request. Moments later, the HTTP client resolves the same hostname again. This time the answer points at a loopback address, a private network, or another destination the service was supposed to keep out of reach.
Both pieces of code can appear correct in isolation. The validator rejected forbidden addresses. The client connected to the hostname it was given. The failure sits between them: the security decision was made about one DNS result, while the network operation used another.
DNS rebinding exploits that gap. It is often discussed beside server-side request forgery because both can turn an application into a network intermediary. The more precise engineering issue is temporal binding. A hostname is not a stable network endpoint, and approval of one resolution does not automatically authorize every later resolution of the same name.
A hostname carries identity, not a fixed address
Applications routinely accept hostnames in webhook targets, import URLs, image fetchers, link preview services, package registries, callback endpoints, and administrative integrations. Hostnames are useful precisely because their address mappings can change without changing the name presented to users or applications.
That property becomes dangerous when validation treats the name-to-address mapping as permanent.
Consider a service that accepts https://example.invalid/resource. Before allowing the fetch, it resolves the hostname and checks the returned IP addresses against a policy. Addresses in loopback, link-local, private, or otherwise sensitive ranges are rejected. A public address passes.
If the HTTP stack performs a fresh lookup during connection establishment, the hostname can produce a different result. An attacker controlling the authoritative DNS data can arrange for the first answer to contain an allowed public address and a later answer to contain a prohibited address. Short DNS time-to-live values can make rapid changes ordinary from the resolver’s perspective, although cache behavior and rebinding feasibility vary across resolvers and client stacks.
The key distinction is simple: validation of a DNS answer is not validation of a hostname for all future connections.
Resolution is part of the security-sensitive operation
Security controls are strongest when the object being checked is the object being used. For outbound network access, that object is ultimately the destination selected for the connection, not merely the hostname string supplied earlier.
A design that performs this sequence has a split boundary:
resolve name -> inspect address -> approve name -> resolve name -> connectThe second resolution can invalidate the evidence gathered from the first.
A safer architecture couples policy enforcement to connection establishment. The application resolves candidate addresses, applies destination policy to those addresses, then ensures the connection uses an approved result rather than silently resolving the hostname again. The exact mechanism depends on the networking library and runtime. Some clients permit a custom resolver or dialer; some abstractions make address selection less visible; connection pools can add another layer because a request may reuse an existing connection instead of creating a new one.
This is not an argument for bypassing normal TLS hostname verification. The hostname remains important for certificate validation and application semantics. The network destination and the TLS identity solve different problems. A system can connect to a policy-approved IP address while still verifying that the peer certificate is valid for the intended hostname, provided its client stack supports that separation correctly.
Redirects create fresh destination decisions
Even a correctly bound initial connection does not settle the entire request if redirects are followed automatically.
An allowed public endpoint can return a redirect to a different hostname. The new hostname can resolve to an internal address, or it can participate in its own rebinding sequence. Treating redirect following as a transparent HTTP feature can therefore move the request beyond the boundary that was checked for the original URL.
Each redirect target is a new outbound destination and needs the same policy treatment as the first target. That includes scheme restrictions, hostname handling, address classification, port policy, and connection binding. Redirect limits remain useful for controlling loops and resource consumption, but a small redirect count does not replace destination authorization.
The same principle applies when application protocols contain indirect references. A document fetched from an approved host might name another resource for the service to retrieve. Whether that second fetch is permitted is a separate policy question, even if application logic presents both operations as one feature.
Address classification is broader than private IPv4
A filter that rejects only familiar RFC 1918 IPv4 ranges leaves substantial gaps. Sensitive destinations can include IPv4 loopback, link-local space, IPv6 loopback, IPv6 link-local addresses, unique-local IPv6 ranges, unspecified addresses, and infrastructure-specific endpoints reachable from the service environment.
Cloud instance metadata services are a prominent example of infrastructure-local targets, but they are not the only assets at risk. Internal control planes, service meshes, database listeners, container management interfaces, developer services, and host-local daemons may all be reachable from an application that was intended to contact only external systems.
Address parsing also needs to use a canonical IP representation rather than fragile string prefixes. IPv6 has multiple textual forms for the same address, and IPv4 addresses can appear inside IPv6 forms. A mature policy classifies parsed addresses according to the runtime’s networking semantics and the deployment’s actual trust boundaries.
DNS answers can contain multiple addresses as well. Approving a hostname because one returned address is public is insufficient if the client may select another returned address. Policy needs to cover every address eligible for connection, or the dial path must be constrained to the specific approved address.
Proxies move the enforcement point
Outbound proxies complicate the picture because the application process may not perform the final DNS lookup or TCP connection itself.
With an HTTP proxy, the client can send a hostname to the proxy and ask the proxy to reach it. In that arrangement, validating an address locally and then handing only the hostname to the proxy can recreate the same split: the application inspected one resolution, while the proxy used another.
A secure design has to identify where destination resolution actually occurs and place enforceable policy at that point. In some environments, the better control is an egress proxy or gateway that resolves names and applies network policy centrally. In others, the application must constrain its own dialer. Defense at both layers can be valuable, but only if their semantics are understood rather than assumed to be equivalent.
Service meshes, NAT gateways, DNS forwarders, and container networking can similarly change the apparent destination. Security review therefore needs the effective network route, not only application source code.
DNS pinning has operational costs
Binding a request to a validated address closes a security gap, but aggressive address pinning can conflict with legitimate infrastructure behavior. Large services may rotate addresses for load balancing, failover, regional routing, or content delivery. Long-lived clients that pin one address indefinitely can retain a dead endpoint or defeat traffic-management decisions.
The useful security property is narrower: the address used for a particular security decision must remain bound to the connection attempt governed by that decision. A later independent request can perform a fresh resolution and a fresh policy check. This preserves normal DNS dynamism without allowing unchecked drift between approval and use.
Connection pooling adds nuance. Reusing an established connection does not require another DNS lookup, so the peer remains the endpoint chosen when that connection was created. Pools still need sensible lifetime and failure behavior, and applications must avoid assuming that a hostname’s current DNS state describes every pooled connection already open for it.
Egress controls reduce the blast radius
Application validation should not be the sole barrier between an outbound fetch feature and sensitive network services. Network-level egress controls can make entire destination classes unreachable even if URL validation contains a defect.
The strongest boundary depends on the deployment. A workload that only needs public HTTPS access may be able to route outbound traffic through a controlled proxy and deny direct access to internal address space. A service that legitimately contacts both internal and external systems needs finer segmentation, perhaps separating fetch workloads from privileged application components.
Such controls are especially valuable because URL handling accumulates edge cases: redirects, alternate address families, proxy behavior, DNS caching, connection reuse, parser discrepancies, and protocol-specific features. Network policy cannot make unsafe application logic correct, but it can keep a parsing or rebinding mistake from becoming unrestricted internal reachability.
The durable rule is to bind evidence to use
DNS rebinding is one instance of a broader security pattern: mutable names make poor stand-ins for the objects a policy actually governs. A hostname can remain identical while its resolution changes, just as a filesystem name can remain identical while the object behind it changes.
For outbound requests, the relevant evidence includes the resolved destination, the policy applied to it, and the connection that consumes that decision. Keeping those elements together avoids a fragile promise that an approved hostname will continue to mean the same network location.
DNS remains dynamic by design. Secure request handling does not need to make it static. It needs to prevent that dynamism from occurring unnoticed between authorization and connection.