Free tools Windows power users keep installed
One-click scans. No signup required.
A domain can return different IP addresses on different DNS lookups. DNS rebinding turns that ordinary flexibility into an attack: a page served from an attacker-controlled domain can prompt a victim’s browser to send later requests to an address on the victim’s internal network. The browser may still treat those requests as coming from the same web origin because the scheme, hostname, and port have not changed.
How can one domain point to different IP addresses?
DNS translates a hostname, such as example.test, into an IP address that a computer can contact. A hostname is not permanently tied to one address: DNS answers can change between lookups. That is useful for legitimate reasons, including moving a service or distributing traffic across servers.
As an Amazon Associate I earn from qualifying purchases.
DNS rebinding uses changing answers in a different way. An attacker arranges for a controlled hostname to resolve first to a public server that serves malicious web content, and later to an IP address on the victim’s private network. A short DNS time-to-live (TTL) can encourage another lookup sooner; it does not, by itself, guarantee when a browser or other component will make that lookup.
How does DNS rebinding turn into a browser attack?
- The victim loads a page. The attacker gets the victim’s browser to load executable content from a hostname the attacker controls. At first, DNS directs that hostname to the attacker’s public server.
- The answer changes. When the browser later looks up the hostname again, the attacker’s DNS arrangement returns an address on the victim’s internal network.
- The page sends requests. The malicious script makes requests using the same hostname, but the network connection may now reach an internal service instead of the attacker’s public server.
- The outcome depends on the target. If the internal service accepts and mishandles those requests, the browser may be used as a proxy to interact with it. Depending on the service and its defenses, that could expose or change data, enable unauthorized actions, or help scan internal hosts.
These are prerequisites and possible outcomes, not a guarantee that every attempt succeeds. The victim must load the attacker’s executable content, the name must be resolved again, and the internal service must be reachable and vulnerable to the resulting requests.
#1 Best Overall
Why might the browser treat the changed destination as the same site?
A browser origin is generally defined by the combination of scheme, host, and port. For example, a change in IP address does not necessarily change the origin if a request still uses the same scheme, hostname, and port. DNS determines which network address is reached for a DNS-named host, while the browser’s origin checks are based on the name and other origin components. Rebinding exploits the gap between those two facts.
RFC 6454 describes the security dependency directly: “In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities.” The same-origin policy is not a general guarantee that a request reaches the same machine each time.
Rank #2
MITRE CAPEC-275 illustrates the issue with a public address and an internal one: “Because the same name resolves to both these IP addresses, browsers will place both IP addresses (1.3.5.7 and 192.168.1.2) in the same security zone and allow information to flow between the addresses.” That describes the example attack model; it should not be read as a guarantee about every modern browser or every configuration.
Which defenses reduce DNS rebinding risk?
No single control necessarily covers every route to an internal service. The useful question is where a defense is enforced and whether it protects the specific service and network path at risk.
Rank #3
| Control | Where it applies | What it does | Trade-off or limit |
|---|---|---|---|
| IP pinning | Browser or client | Continues using an address already recorded rather than switching destinations based on a later DNS answer. | MITRE notes a compatibility trade-off: pinning can conflict with legitimate sites. The cited material does not establish current behavior across browsers. |
| HTTP Host-header validation | Application server | Rejects requests whose Host header names a hostname the service should not accept. | It helps only when the relevant service validates the header correctly; it does not filter DNS answers or protect unrelated services. |
| DNS answer filtering | DNS resolver | Prevents external names from resolving to internal addresses. | It constrains answers seen through that resolver; it does not replace application checks or establish protection for every resolution path. |
For browser and client behavior
IP pinning limits the ability of a later DNS answer to redirect a hostname to a different address. It can also interfere with legitimate sites whose addresses change, so it involves a compatibility trade-off. The sources cited here do not establish which current browsers pin addresses, for how long, or under what conditions; do not assume a particular browser provides this protection by default.
For internal web applications
Validate the HTTP Host header and reject unexpected hostnames. This matters because the request can reach an internal service while carrying the attacker-controlled hostname. Stanford’s Web Security Research also identifies server-side Host-header checking as necessary for attacks against the browser itself. A service should not rely on the assumption that only trusted clients can send it a request.
For DNS and network boundaries
Use resolver filtering that blocks external names from resolving to internal addresses. Stanford’s research page also describes placing sensitive content behind a firewall resistant to circumvention, rather than exposing it on a default virtual host. These controls should be checked against the actual routes and services they are meant to protect; filtering at one resolver or guarding one application does not establish that every internal destination is covered.
What should administrators check?
- Identify exposed internal services. Determine which services are reachable from user devices and what they accept from HTTP requests.
- Check hostname handling. Verify that each web service rejects unexpected Host-header values instead of serving sensitive functionality under any hostname.
- Review DNS filtering. Confirm whether the resolver used by clients blocks external names from returning internal addresses, and consider whether clients can use another resolution path.
- Validate network controls. Check that sensitive services are not reachable through a route that bypasses the intended firewall boundary.
- Do not rely on TTL alone. A short TTL can help an attacker seek another lookup, but TTL behavior is not a complete defense. Controls should also protect the service or restrict the destination.
What the historical cost estimate does—and does not—mean
Stanford Web Security Research’s 2007 paper summary stated that it cost “less than $100 to temporarily hijack 100,000 IP addresses.” This is a historical claim about a particular research scenario, not a current price, general estimate, or measure of present-day attack capability.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
