A browser decides whether two requests share an origin using the URL’s scheme, host, and port. DNS decides which machine that host actually reaches, and it’s free to answer differently a minute later. Those two systems answer different questions, and neither consults the other.
DNS rebinding lives in that gap. An attacker who controls a hostname serves code from one address, then changes the DNS answer so the same hostname points somewhere inside the victim’s network. The origin the browser trusts never changes, but the machine on the other end does.
Browser trust is attached to the hostname
Same-origin comparison uses scheme, host, and port. The resolved IP address isn’t part of it.
Load a page and its JavaScript from http://portal.example.com and a later request that script makes back to http://portal.example.com is still same-origin, no matter what DNS has done underneath in the meantime. Resolution happens below the comparison the browser is making.
Changing addresses is normal behavior, incidentally. Large services rotate answers constantly for load distribution and failover, which is also what fast flux exploits toward a different end. Rebinding uses the same freedom to move where an existing trust relationship points.
The attacker controls both the page and the zone
The attack starts from a domain the attacker legitimately owns. At first its authoritative server hands out a public address:
portal.example.com. 5 IN A 192.0.2.25The browser connects there and loads the attacker’s page and its JavaScript. Then the same authoritative server starts answering differently:
portal.example.com. 5 IN A 192.168.1.50The URL hasn’t changed by a character. The address behind it is now on the victim’s private network, somewhere the public internet was never able to reach.
Nothing here is forged, no resolver is compromised, and no cache is poisoned. Both answers are entirely valid authoritative responses for a zone the attacker controls, which is what makes rebinding awkward to defend against at the DNS layer.
http://portal.example.com while that name resolves to 192.0.2.25. A later lookup returns 192.168.1.50. If the browser makes another request to the same URL and uses the new resolution, that request reaches a private service while the browser still treats it as the same origin it originally trusted. This is the classic flow, and current browser controls, described below, may block it outright.
TTL is only one timer in the path
A short TTL can make a new answer visible sooner, but publishing a five-second TTL doesn’t mean every browser re-resolves in five seconds.
The recursive resolver ordinarily answers from cache while the record is unexpired, though it may evict early or, under serve-stale policy, keep using expired data when refresh fails. The operating system may cache separately. Browsers and their network stacks cache results, retain address sets, and reuse existing connections, any of which can delay or prevent a rebind. Historically some browsers also pinned an address for a fixed period as a dedicated countermeasure, an approach the original research judged ineffective on its own and one whose behavior varies by implementation. None of it should be treated as a reliable defense.
The attack doesn’t depend on any exact TTL behavior, only on the client eventually using the changed address. It’s the same lesson that runs through all of DNS, where authoritative intent doesn’t instantly replace cached state elsewhere.
The internal service still has to accept the connection
Rebinding changes reachability, not authorization. The target has to be listening at the new address on the origin’s port, since the port is part of the origin, and everything the application does next still applies.
Validating the request authority stops a rebinding request at ingress. That authority carries the attacker’s hostname rather than the internal service’s usual name, so a service checking it against an allowlist rejects the request. The field differs by protocol version, Host in HTTP/1.1 and :authority in HTTP/2 and HTTP/3. The check belongs as early as possible, at a reverse proxy or default virtual host that refuses unknown names. It supplements authentication rather than replacing it. A service that trusts requests purely because they arrived from a private network has a much weaker boundary than one that authenticates the requester.
TLS adds a separate identity check
Rebinding examples are easiest to demonstrate over plain HTTP for a reason. HTTPS requires the server at the new address to present a certificate valid for the hostname in the URL, and a private service holding a certificate for some unrelated internal name fails that validation, so the request is never sent.
That closes many simple HTTPS paths. It changes nothing about the DNS mechanism. It just adds an identity boundary after resolution, and whether a given target can satisfy it depends on how that target is configured.
DNSSEC authenticates both answers
DNSSEC doesn’t help here.
If the attacker’s zone is signed with a valid chain, both the public-address answer and the later private-address answer validate, because both genuinely are authentic data authorized by that zone. DNSSEC proves provenance. It places no constraint on a zone owner changing their own records.
Authenticating that data came from its zone says nothing about whether the zone is being used honestly.
Defenses sit at the resolver, the browser, and the service
A resolver can apply local policy to reject upstream A and AAAA answers that map names into private, loopback, link-local, or other locally sensitive prefixes, with explicit exceptions for approved internal zones. BIND and dnsmasq both ship this. It’s policy rather than protocol, and it has limits. Public names legitimately resolve to private addresses in split-horizon DNS, VPN-dependent services, and development environments, and a client using its own encrypted resolver bypasses the local policy entirely.
Browser defenses have moved considerably. Chromium developed Private Network Access, formerly CORS-RFC1918, and has since replaced that approach with Local Network Access, which gates requests from public pages into local network resources behind a permission prompt available only in secure contexts. The practical consequence for the plain-HTTP example above is that an insecure public origin can’t obtain that permission at all. Behavior still varies by browser, version, and request mechanism, so exposure is worth testing rather than assuming in either direction.
The service-side controls from earlier belong in this list too, and are the ones fully under a defender’s control.
What DNS telemetry shows
Resolver logs and passive DNS can each catch part of a rebinding sequence, such as a hostname resolving public and then private, very short TTLs around the transition, repeated re-resolution of one name, or answers carrying loopback or RFC 1918 addresses where they don’t belong.
The two sources answer different questions. Passive DNS shows that both answers existed over time, but it can’t show that one client consumed both. Per-client resolver logs are what tie repeated lookups to a single machine. Either way, context decides the meaning. A public hostname resolving to 192.168.1.50 might be a rebinding attempt, an intentional internal design, a VPN-dependent service, or plain misconfiguration. DNS can show that the destination moved. Establishing what the client then did with it takes browser and application telemetry.
Summary
DNS rebinding works because the web origin model and the DNS addressing model answer different questions. The browser asks whether scheme, host, and port still identify the same origin. DNS decides, moment to moment, which machine that host reaches.
An attacker holding a zone can move that address without forging anything and without defeating DNSSEC. Short TTLs smooth the transition, but caches, browser permission controls, TLS, resolver policy, and the target application all sit between the attempt and anything useful.
The hostname stays trusted while the destination underneath it moves.