What is DNS rebinding, and how do you stop it?
DNS rebinding abuses the fact that a browser's same-origin policy trusts a hostname, not the IP address behind it: an attacker's DNS server first answers a lookup with its own address to pass an initial same-origin check, then swaps the answer to a private, internal address — letting a page you're viewing reach devices on your own network that were never meant to be reachable from outside it.
By AdminKit team, Netbase JSC · Updated October 23, 2026
Why DNS rebinding works at all
A browser’s same-origin policy decides whether a page’s JavaScript can read data from another page by comparing hostnames — not IP addresses. DNS rebinding exploits the gap between those two things. An attacker controls the DNS server for a domain they own, and configures it to answer the first lookup with their own server’s address, so a victim’s browser loads the page normally and treats it as a legitimate origin. The attacker then sets a very short TTL on that DNS record and, once the victim’s browser or resolver re-resolves the name, switches the answer to a private address — commonly one of the ranges RFC 1918 reserves for internal networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or 127.0.0.1 itself. The browser never sees the hostname change, so it keeps treating requests from that page as same-origin, even though they now land on a device inside the victim’s own network.
What an attacker can actually reach this way
The academic paper that first formalized this attack, Protecting Browsers from DNS Rebinding Attacks by Jackson, Barth, Bortz, Shao and Boneh, showed that a successful rebind effectively turns a victim’s browser into an open proxy that can reach anything the victim’s network can reach — including hosts with no direct path from the public internet at all. In practice that means a router’s web admin panel, a smart-home hub’s local API, a network printer, or an internal dashboard someone assumed was safe simply because it “isn’t exposed to the internet.” If that device’s admin interface doesn’t require its own authentication — a common assumption for LAN-only devices — a rebind attack can read its configuration or send it commands, entirely through a tab the victim thinks is just browsing an ordinary website.
How to check whether you’re exposed
There’s no single “rebinding check” the way there is a port-exposure check, because the vulnerability lives in how a device or resolver handles DNS answers that resolve to private addresses, not in whether a port responds publicly. Two things are worth confirming on your own network:
- What your DNS resolver does with a public-looking name that resolves to a private address. Use AdminKit’s DNS lookup tool to inspect a hostname’s current answer and TTL — an unusually short TTL on a record you don’t control is one of the signatures rebinding attempts rely on.
- Whether devices on your network require authentication regardless of where a request appears to originate. A router or IoT hub’s admin interface that trusts “requests from the LAN” without checking credentials is exposed to rebinding even if its own firmware has nothing else wrong with it.
How to prevent DNS rebinding
- Enable rebind protection on your DNS resolver. Resolvers built on dnsmasq (including many router firmware images and Pi-hole) can drop any answer that resolves a public-looking query to a private IP range, stopping the attack before a browser ever sees the rebound address.
- Never rely on source network location as authentication. The OWASP SSRF Prevention Cheat Sheet makes the same point for server-side requests: validating a hostname once and trusting it afterward doesn’t hold, because the IP behind that hostname can legitimately change between the check and the connection. Internal admin interfaces should require their own login, not just “came from inside the network.”
- Keep DNS answer TTLs sane on infrastructure you control, and be suspicious of unusually short TTLs on third-party domains your internal tooling trusts automatically.
- Segment management interfaces so that even a successful rebind against one device can’t reach others — a flat network makes every additional device reachable the moment one DNS resolver fails to filter correctly.
Related checks
DNS rebinding and certificate validation solve adjacent but different problems — one is about which IP a hostname is allowed to resolve to, the other is about whether the server on the other end is who it claims to be. See our guide on reading a TLS/SSL certificate check result for the latter, and is my router’s DNS hijacked for a related but distinct DNS-tampering scenario worth ruling out on the same network.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
What is DNS rebinding in plain terms?
It's a technique that tricks a browser's same-origin security check, which only looks at a hostname, by changing what IP address that hostname resolves to after the page has already loaded. The browser keeps treating later requests as same-origin because the hostname never changed, even though the IP behind it now points inside your own network instead of the attacker's server.
Is this a flaw in a specific browser?
No — it's a structural gap between how DNS (which maps names to addresses, and can change that mapping at any time) and the same-origin policy (which checks names, not addresses) interact. Every mainstream browser is exposed to the same underlying mechanism unless something else in the stack — a resolver, a firewall, or the target server itself — refuses the rebound request.
Does HTTPS on my internal devices prevent this?
Only partially. TLS proves the server presented a certificate for that hostname, but if an internal device doesn't actually enforce certificate validation, or the attack targets a plain HTTP admin page (common on routers and IoT hubs), TLS does nothing to stop the rebind. The real fix has to happen at the DNS resolver or the target device's own request validation, not the transport encryption.
How do routers and resolvers defend against DNS rebinding today?
Many consumer router firmware images and DNS resolvers (dnsmasq, Pi-hole, and similar) ship a 'rebind protection' option that drops any DNS answer pointing to a private address range when the query came from a public-facing lookup, closing the attack at the resolver before it ever reaches a browser.
How do I check if my own setup is vulnerable?
Confirm whether your router or local DNS resolver has rebind protection enabled — it's often on by default on modern firmware but worth verifying explicitly, especially on older or replaced router firmware. Use AdminKit's DNS lookup tool to inspect what a given hostname actually resolves to and how its TTL behaves, which is the first signal worth checking.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.