What is a DNS rebinding attack?

A DNS rebinding attack tricks a victim's browser into loading a malicious script from an attacker-controlled domain, then changes that domain's DNS record to point to an internal network IP address (like 192.168.1.1). The browser treats the script as same-origin and allows it to access internal devices, routers, and APIs on the local network.

Why is DNS rebinding dangerous?

DNS rebinding bypasses the browser's same-origin policy and network firewalls. A malicious website can use it to scan and interact with your router's admin panel, access IoT devices, exfiltrate data from internal services, and pivot deeper into a corporate network — all from a single page visit.

How do you defend against DNS rebinding?

Defend against DNS rebinding by: using a DNS resolver that blocks rebinding (resolvers that reject responses pointing to private IP ranges), blocking DNS rebinding in your browser (some browsers now include rebinding protection), disabling JavaScript on untrusted sites, and ensuring your router does not accept HTTP admin commands without authentication.

DNS Rebinding Attacks Explained — How Attackers Bypass Your Firewall

DNS rebinding is one of the most clever and underappreciated attacks on modern network architecture. It lets an attacker use a compromised website to scan and interact with devices on your local network — your router, your IoT devices, your printer — all without any malware on your machine. The attack exploits the way browsers trust DNS resolution, and it works even when you are behind a properly configured firewall.

This guide explains how DNS rebinding works, why it is so dangerous, and how to defend against it.

How a DNS Rebinding Attack Works

The attack has two phases, and understanding both is essential to see why it is so effective.

Phase 1 — Legitimate first load

The attacker hosts a malicious web page on a domain they control (for example, evil-site.com). The page contains JavaScript that repeatedly tries to access http://192.168.1.1/admin — a common router admin address. When you visit the page, the first time your browser asks for evil-site.com, the attacker's DNS server returns a legitimate public IP address (say, 203.0.113.5). The browser loads the page, the script starts running, and the browser caches the DNS resolution for evil-site.com as 203.0.113.5.

Phase 2 — The rebind

The attacker now sets an extremely short TTL on the DNS response (as low as 0 seconds). Once the original response expires from cache, the browser asks for the IP again. This time, the attacker returns the internal IP address — 192.168.1.1. The browser now thinks evil-site.com lives at 192.168.1.1. Since the page origin is still evil-site.com, the browser's same-origin policy treats the script as authorized to access that origin. The script can now make HTTP requests to your router's admin panel, read device status pages, and exfiltrate data back to the attacker.

Because the attacker controls both the DNS server and the script, they can rebind at will, repeatedly switching between the public IP (to maintain the browser's trust) and the internal IP (to attack the local network). This is called the "rebind" — the DNS record binding changes over time.

What DNS Rebinding Can Attack

The attack works against any device on your local network that has a web interface and does not require authentication. Common targets include:

Home routers. Most home routers have a web admin panel at 192.168.1.1 or 192.168.0.1. A rebinding attack can access the admin panel, change DNS settings, open ports, or change Wi-Fi passwords — all without the user knowing.

IoT devices. Smart cameras, smart speakers, and home automation hubs often have unauthenticated HTTP APIs. A rebinding attack can read camera feeds, listen to microphone data, or control smart locks.

Development servers. Developers running local servers on 127.0.0.1 or 0.0.0.0 are especially vulnerable. A rebinding attack can read source code, access databases, and pivot into development environments.

Internal corporate services. In enterprise environments, internal tools and dashboards are often accessible from any host on the corporate network. A rebinding attack from a compromised browser can access these tools without any authentication challenge.

The Role of DNS TTL in Rebinding

The entire rebinding attack depends on controlling the TTL (Time to Live) of DNS responses. If the TTL is long (for example, 3600 seconds), the browser's cache holds the legitimate IP for an hour, giving the attacker no opportunity to rebind.

This is why rebinding attacks set the TTL as low as possible — ideally zero. When the TTL expires, the browser re-queries the domain, gets the new (internal) IP, and the rebind succeeds. Resolvers that enforce a minimum TTL (for example, refusing to cache TTLs below 60 seconds) make rebinding significantly harder because the attacker cannot force a fast rebind.

DNSSEC does not prevent rebinding because the attacker's domain is fully legitimate — it just changes what IP it points to. The attack does not involve forgery, only rapid DNS changes.

How to Defend Against DNS Rebinding

Defense requires action at multiple layers:

Use a DNS resolver that blocks rebinding. Resolvers like Cloudflare (1.1.1.1) can be configured to return NXDOMAIN or 0.0.0.0 for DNS responses that resolve to private IP ranges (RFC 1918). This prevents the rebind entirely — the browser gets a blocked response instead of a private IP. Some DNS resolvers, including Quad9, offer this protection by default.

Browser-level defenses. Modern browsers now include rebinding protection. Firefox and Chrome check whether a DNS resolution points to a private IP and block the connection if it does not match the expected origin. DNS-over-HTTPS prevents external DNS manipulation. Keeping your browser updated is one of the most effective defenses.

Protect your router. Change the default admin password. Disable HTTP admin panels entirely if your router supports HTTPS-only administration. Enable WPA3 on your Wi-Fi. These steps limit what an attacker can do even if a rebinding attack reaches your router.

Network segmentation. Separate IoT devices, work machines, and guest devices onto different VLANs or network segments. This limits the blast radius of a rebinding attack — even if one segment is compromised, the attacker cannot access devices on other segments.

Disable JavaScript on untrusted sites. Using a browser extension that blocks JavaScript on untrusted sites (like NoScript) prevents the malicious script from running in the first place. This is the most effective but also the most inconvenient defense.

Testing for DNS Rebinding Vulnerability

You can test whether your DNS resolver blocks rebinding by querying it for a domain that resolves to both a public and private IP. If the resolver returns the private IP without blocking, your network is vulnerable.

Tools like rebind.it and rebinder can test your DNS resolver's rebinding resistance. These tools generate DNS responses with private IPs and measure whether your resolver caches and returns them.

For organizations, running internal penetration tests that include rebinding scenarios is the best way to validate defenses. Include rebinding in your regular DNS audit checks.