DNS rebinding is a cyberattack where a malicious website manipulates the Domain Name System to bypass a web browser’s same-origin policy and reach private, internal networks. Unlike the DDoS-style DNS attacks in this cluster, rebinding isn’t about volume or denial of service at all; it’s a precision technique that turns a victim’s own browser into a proxy for reaching devices and services that were never meant to be internet-accessible.
How DNS Rebinding Works
Initial request.
A user visits a website controlled by an attacker. The attacker’s DNS server resolves that domain to a public IP address hosting malicious code.
A deliberately short TTL.
The attacker sets an unusually short Time-to-Live, often just one second on the DNS record, ensuring the browser won’t cache the resolved address for long.
The rebind.
A malicious script running on the page (usually JavaScript) makes a second request to the same domain name, which the same-origin policy still permits, since it’s the same hostname.
Internal access.
The attacker’s DNS server now answers with a private, internal IP address, something like 192.168.x.x or 127.0.0.1 instead of the original public address.
Bypassing the browser's security model.
Because the hostname never changed, the browser still treats the request as going to the same origin it already trusted, even though the actual destination is now a device on the victim’s own local network. The script can then interact with that internal device as if it had legitimate same-origin access.
Why This Matters: Bypassing a Core Browser Protection
The same-origin policy exists specifically to stop a malicious page from reading or controlling resources on a different origin; it’s one of the most foundational security boundaries in web browsers. DNS rebinding doesn’t break that policy technically; it exploits a gap the policy was never designed to cover. The policy checks whether a hostname matches, not whether that hostname has quietly started pointing somewhere else entirely. Because DNS and browser origin checks were built as separate systems with no coordination between them, a hostname that resolves differently on a second lookup slips through a boundary that, on paper, is still being enforced correctly.
DNS Rebinding Attacks and Browser Vulnerabilities
A DNS rebinding attack specifically targets the relationship between DNS resolution and browser security. This browser DNS rebinding technique can expose a DNS rebinding vulnerability when internal services rely on network location or hostname-based trust instead of strong authentication. By causing the same hostname to resolve first to a public server and later to a private IP address, an attacker can potentially make a victim’s browser interact with internal resources that were never intended to be publicly accessible.
What Rebinding Can Be Used to Do
Reach internal devices and services.
Routers, printers, IoT devices, and internal APIs that are deliberately not exposed to the public internet become reachable through the victim’s own browser.
Exfiltrate data.
Once connected to an internal resource, a script can extract credentials, configuration data, or other sensitive information and send it back to the attacker.
Manipulate internal services.
Administrative interfaces reachable this way can have their settings changed, security features disabled, or services disrupted.
Bypass CSRF protections.
Many cross-site request forgery defenses rely on the same-origin policy to prevent reading security tokens from another origin; rebinding undermines that assumption, letting an attacker capture and reuse tokens that should have been inaccessible.
How to Protect Against DNS Rebinding
DNS rebind protection.
Use firewalls or DNS resolvers that block public domains from ever resolving to private IP address ranges, closing the core mechanism the attack depends on.
DNS pinning.
Configure browsers or local resolvers to cache a domain’s first resolved IP address for a fixed period, regardless of what TTL the DNS record itself specifies; this directly defeats the short-TTL trick rebinding relies on.
Enforce HTTPS on internal services.
Since a valid SSL/TLS handshake requires a certificate matching the expected domain, attackers generally can’t establish one across a rebinding attempt, making the connection fail even if the IP address resolution succeeds.
Validate Host headers.
Configure internal web servers and development tools to reject requests carrying unexpected or unrecognized Host headers.
Require strong authentication on internal devices.
Even ones that are “only” reachable from inside the network rebinding specifically targets the assumption that network location alone is a sufficient security boundary.
A Browser's Trust in a Hostname Isn't a Trust in an Address
DNS rebinding works because browsers and DNS were designed as two separate systems that don’t actually coordinate on what “the same origin” means over time; a hostname stays constant while the address behind it quietly changes, and the browser has no reason to notice. That’s a structural gap, not a misconfiguration, which is why the effective defenses here target the mechanism directly: pinning a resolved address so it can’t change mid-session, rejecting DNS responses that point to private address ranges, and treating “internal network” as a location, not a security guarantee, by requiring real authentication on internal devices regardless of where a request appears to come from.
Frequently Asked Questions (FAQ)
1. What does DNS rebind actually do?
It tricks a browser into treating a device on a private, internal network as if it were part of the same trusted origin as an external website by first resolving a domain to a public address, then switching the same domain to resolve to a private address while the browser still trusts it as unchanged.
2. Should I enable DNS rebinding protection?
For most networks, yes particularly any network with internet-facing browsers that could reach internal devices, routers, or administrative interfaces. The main caveat is that some legitimate uses of Dynamic DNS can resemble rebinding patterns, so protection should be configured carefully rather than blocking all rapidly-changing DNS resolutions outright.
3. How can I check for DNS rebinding vulnerabilities on my own network?
Use a DNS lookup tool to inspect whether a domain alternates between public and private IP addresses across repeated queries in a short window; that pattern is a strong indicator. Dedicated DNS rebind testing tools are also available that simulate the attack safely against a network you control, to confirm whether protections are actually working.
4. What's the difference between DNS rebinding and DNS hijacking?
DNS hijacking involves gaining actual control over DNS infrastructure: a server, router, or registrar to redirect traffic broadly and persistently. DNS rebinding doesn’t require controlling any infrastructure beyond a domain the attacker already owns; it exploits the interaction between DNS resolution timing and browser trust, targeting one victim’s browser session rather than redirecting traffic at scale.
Secure DNS. Block threats before they spread.
Prevent DNS attacks, block malicious domains, and protect critical traffic without disrupting your online services.
