DNS Rebinding Turns Name Resolution Into a Browser Network Pivot
A browser can load active content from a public server, keep the same URL origin, then resolve that origin name to a different IP address later. If the new address reaches a service on a private network, the browser has become a transport path between attacker-controlled code and a target that was never intended to accept requests from the public Internet.
This is the core tension in DNS rebinding. Browser origin checks identify an origin by scheme, host, and port; the resolved IP address is not part of that tuple. DNS, meanwhile, exists specifically to map a host name to network addresses, and those answers can change over time. A security design that treats private address space as sufficient authorization can therefore collide with a browser security model that treats a stable host name as the stable identity.
The attack does not require the browser to ignore the same-origin policy. It exploits the gap between the identity that policy tracks and the network endpoint selected after name resolution.
Origin identity survives an address change
For a URL such as http://panel.example.test:8080/, the browser origin is formed from the scheme, host, and port. An initial DNS answer might direct panel.example.test to an Internet-facing server controlled by an attacker. JavaScript loaded from that server executes with the origin associated with that name.
A later connection to the same origin can trigger another name-resolution decision. If the authoritative DNS service now returns a private or loopback address, the textual origin has not changed. The browser still sees the same scheme, host, and port even though packets can be sent to a different machine.
DNS caching, connection reuse, resolver behavior, browser policy, and address-selection rules all affect whether and when a new address is used. Rebinding is therefore not equivalent to a guaranteed immediate DNS switch. Its security significance comes from the possibility that a stable origin identifier can outlive one particular address mapping.
This distinction is fundamental. An IP address answers a routing question. A web origin answers an authority and isolation question. Treating the two as interchangeable creates a boundary that neither layer actually promises.
The local service receives the attacker’s host name
HTTP carries the target authority in the request. In HTTP/1.1 this appears in the Host field; HTTP/2 and HTTP/3 use the :authority pseudo-header for the corresponding role. A rebinding request aimed at a private IP can therefore still identify the attacker’s domain as the requested authority.
That behavior gives a local service an important enforcement point. A service intended only for a fixed local name does not need to accept every authority merely because the connection arrived on a private interface. Rejecting unexpected host or authority values can stop the request before application routing reaches sensitive handlers.
This control is strongest when the accepted names are explicit and tied to the service’s deployment identity. A permissive virtual host, a default route that accepts arbitrary names, or logic that discards the authority before authorization removes that distinction.
Host validation is not a substitute for authentication. It blocks one useful path through the boundary, but a service that performs privileged operations still needs authorization appropriate to those operations. Network locality and a plausible host value are weak credentials.
Private addressing is reachability, not identity
Internal dashboards, development servers, device administration interfaces, and local agents are often deployed on addresses that cannot be routed directly from the public Internet. That topology reduces exposure, but it does not prove that every request reaching the address was initiated by trusted software.
A browser already has access to networks available to the user’s machine. Attacker-controlled web content executes inside that browser. If name resolution can steer a permitted web origin toward an internal endpoint, the browser supplies reachability that the remote attacker lacks directly.
The security failure appears when the target interprets source location or private routing as authorization. A request arriving from the browser may originate from the local host or local network from the target’s perspective. That observation says little about the authority controlling the script that caused the request.
Loopback has the same conceptual issue. Binding a service to 127.0.0.1 or ::1 prevents remote hosts from opening a direct socket, but it does not establish that every local socket was created by a trusted local application. Browsers, document viewers, extension runtimes, and other software can all originate local traffic under different security contexts.
TLS changes the rebinding constraint
HTTPS adds certificate authentication for the origin name. A browser connecting to a private address for https://panel.example.test/ still expects the TLS endpoint to present a certificate acceptable for panel.example.test. An arbitrary internal HTTP service cannot satisfy that condition merely because DNS points the name at its address.
This raises the bar substantially. The rebinding operator would need the private endpoint to complete TLS for the attacker’s origin name, or some other deployment condition would need to make that certificate check succeed. A certificate valid only for the internal service’s own name does not become valid for the attacker-controlled name after DNS changes.
Plain HTTP lacks that cryptographic name binding. Its authority is weaker because name resolution selects the server without a certificate proving control of the requested host. This makes authority validation at the application or reverse proxy especially important for local HTTP services.
TLS does not make private services safe by itself. A service can still expose risky cross-origin behavior, accept credentials incorrectly, or be reachable through other browser-mediated paths. It does, however, constrain classic rebinding by requiring the endpoint reached after the DNS change to authenticate the original HTTPS name.
CORS and rebinding solve different problems
Cross-Origin Resource Sharing controls selected browser access across distinct origins. DNS rebinding is notable because the attack can preserve the same origin tuple while changing the network destination. A service cannot rely on a restrictive CORS policy to repair a request that the browser still classifies as same-origin.
The Origin request header can still provide useful context for requests that carry it, but a rebinding flow can present the attacker’s domain as the origin because that domain is the browser’s actual origin. Allowing an origin merely because its current DNS answer points to an approved network therefore repeats the same unstable binding.
Server-side authorization should instead be anchored in identities and credentials that remain meaningful when routing changes. Session credentials, cryptographic client identity where appropriate, capability tokens, and explicit service authentication have properties that private IP membership alone lacks.
Browser controls for access from less-private to more-private network address spaces can add another barrier in supporting implementations. Such controls should be treated as defense in depth rather than as permission for local services to accept arbitrary authorities or omit authentication.
DNS defenses have a limited scope
A recursive resolver can detect suspicious answers and refuse to return private, loopback, link-local, or otherwise protected addresses for names obtained from public DNS. Products often describe variants of this behavior as DNS rebinding protection.
That mitigation can be effective at the resolver boundary, but its coverage depends on which resolver the client actually uses and which address classes or naming exceptions the policy applies. Split DNS, VPNs, local development names, service discovery, and legitimate public names that resolve to private addresses can complicate blanket filtering.
Encrypted DNS transport does not inherently remove rebinding. DNS over HTTPS and DNS over TLS protect transport properties between a client and a resolver; they do not make every returned address semantically safe for every application. A resolver can faithfully return an attacker-controlled record over an authenticated encrypted channel.
DNSSEC also addresses authenticity of DNS data, not whether an authenticated address mapping is suitable for a browser to contact. An attacker authoritative for a signed zone can publish signed records for that zone. Authentic data can still describe a security-sensitive routing transition.
Connection reuse can delay the pivot
A DNS answer change does not necessarily produce a new connection. HTTP keep-alive, HTTP/2 multiplexing, HTTP/3 connection behavior, browser connection pools, and DNS caches can keep traffic attached to an existing endpoint after authoritative DNS data has changed.
This implementation reality affects exploit timing and defensive testing. A test that changes a record and immediately observes traffic remaining on the public server does not establish that rebinding is impossible. Conversely, a short DNS TTL does not guarantee that a browser will promptly discard every cached resolution or active connection.
The relevant security question is whether the browser can eventually establish a connection for the same origin to a protected address under the policies in effect. Exact timing is secondary and varies across stacks.
Service defenses should not depend on predicting that timing. A local endpoint that rejects unknown authorities and requires authorization remains protected across DNS cache and connection-pool variations.
Reverse proxies can either enforce or erase the boundary
Many internal services sit behind a reverse proxy that terminates HTTP or TLS and forwards requests to an application. That proxy is often the earliest component with enough information to reject an unexpected authority.
A strict virtual-host configuration can map only approved names to the sensitive backend and return an error for all others. A catch-all default host can do the opposite: it can route an attacker-controlled authority to the same backend, converting network reachability into application access.
Forwarded metadata also needs a clear trust model. If a proxy rewrites Host, constructs forwarding headers, or normalizes authority before the application sees it, the application may be unable to distinguish an approved request from one that entered through an unintended name. Validation belongs at a layer that still has trustworthy access to the original request authority.
The same principle applies to local development proxies and device gateways. Convenience defaults that accept any host reduce friction, but they also remove a name-based boundary that is valuable when browsers can reach the listener.
The durable boundary sits above routing
DNS rebinding exposes a mismatch rather than a defect in DNS alone. DNS is allowed to change address mappings. Browsers are designed to attach web authority to origins rather than to fixed IP addresses. Private networks are designed to constrain routing, not to authenticate the software that initiated traffic from a reachable machine.
A robust service design accounts for all three facts. Sensitive local and internal endpoints accept only intended authorities, authenticate operations that require privilege, constrain cross-origin behavior where relevant, and avoid treating source address class as sufficient proof of trust. Resolver and browser protections can reduce exposure further, but they sit outside the service and can vary across environments.
The operational consequence is clear: an endpoint hidden from direct Internet routing can still be part of a web-facing attack surface when a browser can reach it. The security boundary has to survive a change in name resolution, because the routing layer does not carry the authorization semantics that the application needs.