DNS Rebinding Attacks Explained: Risks and Defenses

Most security checks that involve a domain assume its IP address is stable enough to validate once and trust afterward. DNS rebinding exploits exactly that assumption. An attacker controls a domain's DNS and configures it to resolve to a normal, public IP address at first -- passing whatever validation a target system performs -- and then changes the answer to an internal address (like 127.0.0.1 or an internal 10.x.x.x range) for a later request, after the check has already passed.

Why this is more than a theoretical trick

A very short TTL makes the attack practical: the attacker sets the record to expire in a few seconds, so a validation check and the actual request that follows it can see two different answers, milliseconds apart, without the victim system realizing the ground shifted underneath it. Any system that resolves a domain once and reuses that IP across multiple operations -- or worse, resolves it once for validation and lets something else resolve it again for the real request -- is potentially exposed.

The only reliable defense

Validating a hostname string isn't enough, and validating an IP once isn't enough either. The only robust defense is checking the actual resolved address against a private/internal-range blocklist at the point where the connection is actually made -- every single time, not just at initial validation. That closes the timing gap rebinding depends on, because there's no longer a window between "checked" and "used" for the answer to change.

• Block private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16), and cloud metadata endpoints -- for both IPv4 and IPv6.
• Re-check on every use, not just once at input validation.
• Treat an IPv4-mapped IPv6 address (like ::ffff:127.0.0.1) as equivalent to its embedded IPv4 address -- rebinding attempts sometimes use this exact encoding to slip past a naive IPv6-only check.

Where this has mattered in practice

DNS rebinding isn't a niche academic concern -- it's been used repeatedly against home routers, smart-home hubs, and other devices that expose an unauthenticated local admin interface on the assumption that only trusted local traffic could ever reach it. A malicious web page, opened in an ordinary browser tab on the same network, can use rebinding to make the victim's own browser -- already trusted by the router simply for being on the local network -- issue requests directly to that admin interface on the attacker's behalf. The browser thinks it's still talking to the original public domain the whole time; only the DNS answer underneath it changed.

A subtler variant: multi-answer rebinding

A more sophisticated version skips waiting for a TTL to expire at all. A single DNS response can legally contain more than one A record, and some client software will simply try them in order, or even round-robin between them across different requests. An attacker can return both a legitimate public address and an internal one in the very same response, relying on the client eventually trying the second entry -- no waiting, no timing window, just exploiting the fact that DNS was never designed to guarantee every address in a multi-answer response is equally trustworthy. It's a good reminder that "check the first address returned" is never sufficient; every address in a response needs the same scrutiny.