A browser visits a domain. The connection succeeds. A few seconds later, JavaScript from that same page makes another request to the same domain. The browser is satisfied: same origin, same domain, everything checks out.
But the server on the other end of the second connection isn't the same server as the first.
How? The domain name didn't change. The origin didn't change. What changed was the IP address the domain resolved to, and the browser didn't notice.
That's DNS rebinding.
Hostname vs IP Address
When you navigate to a domain, the browser doesn't connect to a hostname directly. Hostnames are human-readable names. The network works with IP addresses. DNS translates between the two.
hostname: example.com
↓
DNS query
↓
DNS response: 93.184.216.34
↓
Network connection to that IP
A DNS record has a TTL: a time-to-live value that tells resolvers how long to cache the answer. After the TTL expires, the next query might get a different answer. DNS doesn't guarantee that a hostname always maps to the same IP address. Domain owners can change their DNS records. Load balancers rotate between multiple addresses. Content delivery networks direct users to geographically nearby servers.
None of this is unusual. Changing where a hostname resolves is a normal operational task.
The question DNS rebinding asks is: what happens when the hostname changes where it resolves to between two requests from the same browser session?
The Browser's Security Model
Browsers enforce security decisions based on origins: the combination of scheme, host, and port. Two resources share an origin if all three match.
https://attacker.example:443
↑ ↑ ↑
scheme host port
The browser's origin model is defined by the URL, not by the IP address the hostname currently resolves to. When JavaScript on https://attacker.example makes a request to https://attacker.example, the origin check is the same both times: same scheme, same host, same port. The origin decision and the DNS resolution decision happen at different layers. DNS determines which IP address the connection ultimately reaches, but that resolved address isn't itself part of the origin used for same-origin checks.
This creates a gap.
The Gap Between Origin and Destination
The browser's security model operates at the level of origin: scheme plus host plus port. Network connections operate at the level of IP addresses. These are different layers, and they can diverge.
First resolution:
attacker.example
↓
203.0.113.45 ← public IP, attacker's server
Later resolution:
attacker.example
↓
192.168.1.1 ← private IP, router admin interface
If an attacker controls the DNS for attacker.example, they can cause an initial resolution to point to their public server and later resolutions to point to a private or internal IP. If the browser uses the later DNS answer for a subsequent connection, the network destination can change while the hostname in the URL remains the same. The browser continues trusting requests to attacker.example as same-origin because the hostname didn't change.
The network destination did.
This is the core insight: a hostname is not a permanent network location. The browser's same-origin check is based on the hostname. The network connection goes wherever DNS currently says it should go.
Why TTL Matters
DNS answers are cached. A DNS resolver that recently received an answer for attacker.example won't query again until the TTL expires. A short TTL can make DNS changes observable sooner, but the actual timing depends on caching behavior at multiple layers: the operating system resolver, the browser's own DNS cache, connection reuse, and the behavior of intermediate resolvers. When a cached answer expires and a new query is made, a different answer can be returned.
This is not a deterministic process. Browser DNS caching, connection reuse, and modern network security controls can all affect when and whether a different DNS answer takes effect, and behavior varies across browsers and environments. The timing of when a rebinding condition can be observed is therefore variable rather than guaranteed.
Localhost and Private Networks
What makes DNS rebinding interesting is what an internal IP can reach.
Localhost services, internal management interfaces, home routers, networked devices, and private APIs often assume that network-level locality implies trust. A service running on 127.0.0.1 may have no authentication, or loose access controls, because it was designed to be reachable only from the machine itself. A home router's admin interface may trust requests from 192.168.x.x without requiring a password.
If DNS resolution for attacker.example causes a browser connection to reach one of these internal addresses, the browser's origin is still defined by the URL: attacker.example. The browser hasn't changed its view of the origin. What has changed is the actual network destination the connection reaches. JavaScript running on attacker.example may be able to interact with that internal service's HTTP responses, depending on how the connection is established and what CORS or other controls the internal service exposes.
The gap is between the origin the browser tracks and the network destination the connection actually reaches. Internal services that were designed assuming only local traffic could reach them may not have protections suited to this scenario.
The impact depends entirely on what's reachable and what protections it has. Reaching 192.168.1.1 means nothing if the router requires authentication. Reaching a service with no access controls means more. Impact is not automatic.
The Trust-Boundary Problem
DNS rebinding is fundamentally about the gap between "I validated the hostname" and "I control the network destination."
Consider an application that enforces a policy like: "Only allow requests to trusted-service.internal." This allowlist is based on the hostname. If trusted-service.internal can be made to resolve to an unexpected IP, the allowlist check passes while the connection goes somewhere unintended.
Similarly, a service that trusts requests because they arrive from a known hostname, rather than because of actual authentication, can be reached by any entity that controls how that hostname resolves.
"I trust requests to trusted.example"
↓
trusted.example resolves to...
↓
...somewhere you didn't intend
A hostname isn't a stable network location. It's a name that currently maps to a location. That distinction matters when security decisions depend on where connections actually go.
DNS Rebinding vs SSRF
It's worth distinguishing DNS rebinding from SSRF, since both involve reaching internal services through unintended paths.
SSRF occurs when an attacker influences a server-side HTTP client to make requests to unintended destinations. The server is the actor being manipulated.
DNS rebinding occurs when a hostname's DNS resolution is manipulated to cause a client, typically a browser, to connect somewhere different than intended while the hostname remains constant. The browser is the actor.
SSRF:
Attacker → vulnerable server → internal destination
DNS rebinding:
Attacker's page in browser → DNS manipulation → internal destination
They can overlap conceptually when a server-side application uses a hostname allowlist that doesn't also validate the resolved IP address. In that case, DNS rebinding against the hostname can potentially satisfy the allowlist while directing connections to an unintended destination.
Defenses
The defenses for DNS rebinding operate at different layers depending on the context.
Require explicit authentication on internal services. Services that are only meant to be accessible internally should still require authentication. Relying on "it can only be reached from the local network" doesn't hold if the local network can be reached by something that wasn't intended to be local. This is the most broadly applicable defense because it doesn't depend on network-level controls holding perfectly.
For server-side applications making outbound requests: validate the resolved IP, not just the hostname. An allowlist of hostnames is different from an allowlist of network destinations. When a server-side application makes HTTP requests and the security property depends on which network destination is reached, validating only the hostname is insufficient. The resolved IP should also be checked against permitted ranges. This is where the SSRF overlap is most relevant.
Reject unexpected private and loopback addresses in outbound request validation. Applications that fetch user-supplied URLs or make outbound requests based on configured hostnames should check resolved destinations against private and loopback ranges when those aren't expected targets.
Network segmentation and egress controls. Limiting what internal services are reachable from what network positions reduces the scope of what a DNS rebinding condition can expose.
Don't treat network locality as a substitute for authentication. A service that requires proper credentials before responding is more resilient than one that relies on "only trusted clients can reach this endpoint." Internal placement is a weak guarantee, not a security control.
A hostname is a name, not a permanent network destination. DNS answers can change, and when they do, the browser's origin model, which is based on the URL, may not reflect where the network connection actually goes.
For server-side applications, that means hostname allowlists alone may not be sufficient when the security property depends on which network destination is reached. For internal services, it means that network locality is a weak trust boundary without proper authentication on top of it.
That's the gap DNS rebinding exploits. The hostname stays constant. The network destination doesn't have to.
