What is a DNS rebinding attack?

Sajjad
DNS
10 Oct, 2026

A DNS rebinding attack is a technique that lets a malicious website use your browser to reach services on your private network or your own computer, such as a router's admin page, a smart TV or a development server on localhost. It works by making a domain the attacker controls resolve first to the attacker's server, and then, moments later, to an internal IP address such as 192.168.1.1 or 127.0.0.1. Because the browser still sees the same domain name, its same-origin policy treats both servers as the same site, so the attacker's JavaScript can send requests to the internal device and read the responses.

Rebinding is an old idea that keeps coming back, because so many devices and local tools assume that anything able to reach them must be trusted. In this article you'll learn why the same-origin policy is vulnerable to it, how an attack unfolds step by step, what kinds of services are at risk, and the layered defences that stop it: in your applications, in your DNS resolver and in the browser.

Why DNS Rebinding Is Possible

The Same-Origin Policy Trusts Names, Not Addresses

Browsers protect you from malicious websites with the same-origin policy. A script loaded from https://news.example can't read responses from https://bank.example, because they're different origins. An origin is made of three parts:

The scheme, such as http or https.
The hostname, such as app.example.com.
The port, such as 80 or 8080.

Notice what's missing: the IP address. The browser decides what's "the same site" by name. It doesn't check whether the name still points to the same server it did a minute ago. DNS rebinding exploits exactly that gap.

DNS Answers Can Change at Any Time

The owner of a domain controls its DNS records, including their TTL, the time a resolver or browser may cache the answer. An attacker running their own authoritative nameserver can give a very short TTL, and give different answers to the same question at different moments. Nothing in DNS forbids a public domain from resolving to a private address like 10.0.0.5.

Local Services Trust the Network

Many devices and programs on a home or office network assume that a request arriving from inside the network must be legitimate. Routers, printers, smart speakers, media servers, IoT hubs and development tools often run web interfaces or APIs with weak or no authentication. A browser running on your laptop is inside the network, so if it can be convinced to send requests on an attacker's behalf, those assumptions fall apart.

How a DNS Rebinding Attack Works

Here's the general sequence, described at a conceptual level so you can recognise it and defend against it.

The lure: You visit a page at rebind.attacker.example, perhaps through a malicious advert or a link.
First resolution: Your browser asks DNS for rebind.attacker.example. The attacker's nameserver answers with the attacker's public server IP, with a TTL of a few seconds.
The script loads: The page's JavaScript is served from the attacker's server and starts running in your browser under the origin http://rebind.attacker.example.
The cache expires: The script waits until the browser's cached DNS entry expires, which in practice often means a minute or so.
Second resolution: The script makes another request to the same hostname. The browser looks it up again, and this time the attacker's nameserver answers with 192.168.1.1.
The rebind: The browser sends the request to 192.168.1.1, which is your router. Because the origin is unchanged, the same-origin policy lets the script read the response.
The payoff: The script can now read data from the internal service or send commands to it, and pass results back to the attacker through another domain.

From the router's point of view, it received an ordinary request from your laptop. From the browser's point of view, a page talked to its own origin. Neither noticed anything wrong.

What Gives the Attack Away

There's one clue in every rebinding request: the Host header. When the browser sends the rebound request to your router, the header still says Host: rebind.attacker.example, not 192.168.1.1 or router.home.arpa. A service that checks the Host header against the names it expects will reject the request. That's the basis of the most important defence, covered below.

What Is at Risk

Home routers: Admin interfaces can expose settings, Wi-Fi passwords or the ability to change DNS servers.
IoT and smart home devices: Many expose local HTTP APIs for control, which researchers have repeatedly shown can be driven through rebinding.
Media and casting devices: Local APIs on smart TVs and streaming devices have been found to leak information such as device details and nearby Wi-Fi networks.
Desktop software with local web servers: Some applications run a local HTTP API for updates or browser integration. Rebinding has been used in published research against update agents and BitTorrent clients that trusted any request to localhost.
Development servers: Local dev servers, admin consoles and database web UIs are often bound to localhost with no authentication.
Cloud metadata services: Services such as the instance metadata endpoint at 169.254.169.254 are a target when a vulnerable application, rather than a browser, fetches attacker-supplied URLs. The same name-versus-address confusion underlies many server-side request forgery bypasses.

How to Defend Against DNS Rebinding

No single control is enough, because rebinding sits at the meeting point of DNS, the browser and the application. Use several of the following.

1. Validate the Host Header in Every Local Service

This is the most reliable defence, because it fixes the trust problem in the service itself. If you build or run any service that listens locally, reject requests whose Host header isn't one of the names you expect.

Here's a minimal Node.js server that does it:

const http = require("node:http");

const PORT = 3000;
const ALLOWED_HOSTS = new Set([
  `localhost:${PORT}`,
  `127.0.0.1:${PORT}`,
  `[::1]:${PORT}`,
]);

const server = http.createServer((req, res) => {
  const host = (req.headers.host || "").toLowerCase();

  if (!ALLOWED_HOSTS.has(host)) {
    res.writeHead(421, { "Content-Type": "text/plain" });
    res.end("Misdirected request\n");
    return;
  }

  res.writeHead(200, { "Content-Type": "application/json" });
  res.end(JSON.stringify({ status: "ok" }));
});

server.listen(PORT, "127.0.0.1", () => {
  console.log(`Listening on http://localhost:${PORT}`);
});

You can test it with curl by sending a forged Host header, which is what a rebound browser request looks like:

curl -i http://127.0.0.1:3000/
curl -i -H 'Host: rebind.attacker.example' http://127.0.0.1:3000/

The first request returns 200 OK; the second returns 421 Misdirected Request.

Most web frameworks have this built in, so make sure it's switched on rather than disabled for convenience:

Django: The ALLOWED_HOSTS setting.
Ruby on Rails: The config.hosts setting, which Rails added specifically as DNS rebinding protection.
Vite and webpack-dev-server: The allowedHosts option for development servers.

Resist the temptation to set these to "allow everything" to make a tunnel or a container work. List the specific hostnames instead.

2. Require Authentication, Even on Localhost

A local service should not assume that any request it receives is from a trusted user. Require a token, a password or a per-session secret, and don't accept credentials that a browser sends automatically to any origin. If an attacker's script can't authenticate, rebinding only gets them an error page.

3. Use HTTPS for Local Services Where You Can

A rebound request to an HTTPS service fails the certificate check, because the internal device's certificate isn't valid for rebind.attacker.example. HTTPS on internal devices is harder to arrange, but it's a strong defence where you control the device and can issue certificates from an internal CA.

4. Bind to the Right Interface

Services that only need to be reachable from the same machine should listen on 127.0.0.1 or ::1, not 0.0.0.0. This doesn't stop rebinding to localhost from a browser on the same machine, but it prevents other devices on the network being used as stepping stones.

5. Filter Private Addresses at Your DNS Resolver

A resolver can refuse to pass on answers from public domains that point at private addresses. This breaks the attack at the DNS step, for every device on the network, without changing any application.

Unbound does this with private-address, which strips private IPs from answers, and private-domain, which exempts your own internal domains:

server:
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 127.0.0.0/8
    private-address: 0.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10
    private-address: ::ffff:0:0/96

    private-domain: "home.arpa"
    private-domain: "corp.example.com"

The ::ffff:0:0/96 entry covers IPv4-mapped IPv6 addresses, which would otherwise let an attacker express a private IPv4 address in IPv6 form.

dnsmasq, used in many home routers and in Pi-hole, has a single option for the same protection:

stop-dns-rebind
rebind-localhost-ok
rebind-domain-ok=/home.arpa/

stop-dns-rebind rejects upstream answers in private ranges, rebind-localhost-ok allows 127.0.0.0/8 answers, which some DNS-based blocklists rely on, and rebind-domain-ok exempts your own internal domain. Router firmware such as OpenWrt and pfSense exposes the same setting as a DNS rebind protection checkbox. Check that it's switched on.

6. Test Your Resolver

To confirm your resolver filters private answers, publish a test record in a public zone you control:

rebind-test.example.com.  300  IN  A  192.168.1.1

Then query through your own resolver and through an unfiltered public one:

dig @192.168.1.53 rebind-test.example.com A +short
dig @1.1.1.1 rebind-test.example.com A +short

If the protection is working, your resolver returns nothing for the first query, while the public resolver returns 192.168.1.1 for the second. Remove the test record afterwards.

Be aware that resolver filtering is a network-level defence. It doesn't help a laptop when it's on someone else's Wi-Fi, or a browser using DNS over HTTPS to an outside provider, so treat it as a second layer behind application fixes.

7. Keep Browsers Up to Date

Browser vendors have been tightening rules on public websites reaching private addresses. Recent versions of Chrome and other Chromium-based browsers restrict requests from public sites to local network addresses and ask the user for permission before allowing them, and browsers have closed related tricks, such as treating 0.0.0.0 as a way to reach local services. These protections are improving but differ between browsers, so they complement rather than replace the defences above.

A Checklist for Developers and Administrators

Every local or internal web service validates the Host header.
Internal services require authentication, even on trusted networks.
Development servers keep their allowed host lists switched on.
Services that only need local access bind to 127.0.0.1.
Home and office resolvers have DNS rebind protection enabled.
Router admin pages use strong, unique passwords and aren't reachable from the internet.
Browsers and device firmware are kept up to date.

FAQ: DNS Rebinding

It needs your browser to load and run the attacker's page, which can happen through a link, a compromised site or a malicious advert. The page usually needs to stay open long enough for the DNS cache to expire, which is often a minute or more.

HTTPS on your public site doesn't help, because the attack targets services on your local network, not your website. HTTPS on the internal service does help, because its certificate won't be valid for the attacker's domain.

No. The attacker controls their own domain and can sign its records legitimately. DNSSEC proves records are genuine, and in a rebinding attack they are, just pointing somewhere harmful.

A rebound request is sent to the internal device but still carries the attacker's domain in the Host header, because the browser thinks it's talking to the attacker's site. A service that only accepts its own expected hostnames rejects it immediately.

It can break legitimate setups where a public domain points at a private address, such as some split DNS configurations or local services using public hostnames. Add those domains to the resolver's exemption list, such as private-domain in Unbound or rebind-domain-ok in dnsmasq.

They share the same underlying weakness. In SSRF, a server is tricked into fetching a URL, and a rebinding domain can pass an address check at first and then resolve to an internal address when the request is actually made. Resolving once and connecting to that checked address prevents it.

Conclusion

A DNS rebinding attack exploits the fact that browsers decide what counts as the same site by hostname, not IP address. By switching a domain's DNS answer from a public server to an internal address, an attacker's script can reach routers, smart devices and local tools that trust anything on the network, and read their responses as if they were its own.

The strongest fix is in the services themselves: check the Host header, require authentication and use HTTPS where you can. Back that up with DNS rebind protection on your resolver and up-to-date browsers, and the attack loses its footing at every stage.