DNS Rebinding Check: a beginner's guide

DNS rebinding is a class of attack where a malicious website uses DNS to bypass the security boundary that normally separates the public internet from the private network behind a router or firewall. The attack exploits an asymmetry: browsers enforce the same-origin policy on domain names, not IP addresses. If a domain initially resolves to a public IP, then on the next query resolves to a private IP like `192.168.1.1`, the browser considers it the same origin and lets the page make requests to it — even though the page is now talking to a device the website should not be able to reach. The attack was first described in the 2007 Princeton paper by Jackson, Barth, Bortz, Shao and Boneh and remains a real threat against home routers, IoT hubs, cryptocurrency wallets, and developer tools.

Rebinding is rotation, not static private IPs. The most common mistake in rebinding tooling is to treat a domain as "vulnerable" because it returns a private IP. That's not rebinding — that's just a misconfiguration. Real rebinding is the rotation between public and private addresses across queries: the first request sees a public IP (the page loads), then a follow-up DNS lookup with a low TTL sees a private IP (now the JavaScript is talking to your router). A check that fires on a single private-IP response is calling everything rebinding; a check that observes rotation across multiple queries is testing the actual attack model. Tooling like NCC Group's Singularity is the operational reference.

Resolver-side filtering matters. RFC 6303 recommends that recursive resolvers refuse to return RFC 1918 addresses for public domains — that's the defense baked into Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9. But many corporate resolvers don't filter, and home routers often serve their LAN's own resolver that doesn't either. So the practical question "are my users exposed?" depends on which resolver they use. A meaningful check probes multiple resolvers and reports which ones filter and which leak.

The five things a real rebinding check looks at:

• Multi-query rotation. Send the same query 3+ times, spaced 2-5 seconds apart, with `cd=1` to bypass resolver-side filtering. Real rebinding shows public IPs in some rounds and private IPs in others.

• Resolver filter visibility. Query the same name at multiple public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) and report which ones drop the private answers per RFC 6303 and which ones pass them through.

• Private-IP coverage. RFC 1918 (`10/8`, `172.16/12`, `192.168/16`), loopback (`127/8`), link-local (`169.254/16`), CGNAT (RFC 6598 `100.64/10`), cloud-metadata (`169.254.169.254`), TEST-NET (RFC 5737), plus IPv6 equivalents (`fc00::/7`, `fe80::/10`, NAT64, Teredo, 6to4).

• TTL. Very short TTLs (<60s) make rebinding fast enough to be useful to an attacker.

• CNAME chain. Rebinding sometimes hides behind a CNAME that itself rotates — following the chain is part of the test.

Three questions a rebinding check answers:

• Is this domain rotating between public and private addresses across queries — the actual rebinding signature?

• Which public resolvers filter the private response per RFC 6303, and which leak it through?

• Are my users (depending on which resolver they use) exposed?

The cost of ignoring DNS rebinding is the small-but-real risk that a user visiting a normal-looking website ends up with an attacker reaching into their router or development machine. The defenses are mostly application-level: bind internal services to localhost rather than `0.0.0.0`, validate destination IPs (not just hostnames) before making outbound requests, require auth on internal endpoints, and check the `Host` header. At the resolver layer, RFC 6303 filtering is the right default.

In one sentence: Detect [DNS (Domain Name System)](/guides/dns-lookup) rebinding vulnerability

Tests if a domain's DNS (Domain Name System) configuration is vulnerable to DNS rebinding attacks — referenced in OWASP Top 10 (2021) A10: Server-Side Request Forgery. DNS rebinding is a subset of SSRF attacks that exploits DNS to bypass same-origin policy and access internal networks.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

DNS (Domain Name System) rebinding is the rotation of a domain's answer between public and private addresses across queries — that's how attackers escape the same-origin policy. This endpoint runs the actual rotation test: 3 queries spaced 2 seconds apart, with `cd=1` to bypass resolver-side filtering, looking for round-to-round changes in the IP (Internet Protocol address) set's public/private mix. In parallel it queries multiple public resolvers (Cloudflare, Google, Quad9) and reports which ones drop the official internet standard results per the official internet standard — telling you which of your actual users (depending on which resolver they use) are exposed. Static checks still run: detection of the official internet standard, loopback (127/8), link-local (169.254/16), cloud metadata (169.254.169.254), CGNAT (the official internet standard), TEST-NET ranges (the official internet standard), and the IPv6 (Internet Protocol version 6) equivalents (fc00::/7, fe80::/10, NAT64, Teredo, 6to4).

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the DNS Rebinding Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Most "DNS (Domain Name System) rebinding checkers" only test for static private IPs and call that "rebinding" — but real rebinding is rotation, not static misconfiguration. The multi-query rotation test makes the endpoint live up to its name. The multi-resolver filter visibility answers the question users actually have: "are my users exposed?" — public resolvers (1.1.1.1, 8.8.8.8) drop the official internet standard per the official internet standard, but internal corporate resolvers often don't, and the response shows you which.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Assess if any external domains used by your application could resolve to internal IPs. Critical for applications that fetch user-supplied URLs (image proxies, OAuth callbacks). Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the DNS Rebinding Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the DNS Rebinding Check tool is built for you:

• Is my domain pointing to the right place right now?

• Did the DNS change I just made actually take effect everywhere in the world?

• Is anything in my DNS misconfigured in a way that could break email or break the website?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders running their own infrastructure, marketers coordinating launches, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you're flying blind on the one piece of config that decides whether your website and email work at all. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the DNS Rebinding Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a network security, and an application security engineer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Web Application Security

Imagine you're a security engineer. Assess if any external domains used by your application could resolve to internal IPs. Critical for applications that fetch user-supplied URLs (image proxies, OAuth callbacks).

Why it matters: Identify and mitigate DNS (Domain Name System) rebinding risks before exploitation.

Story 2: Internal Network Protection

Imagine you're a network security. Evaluate if external domains could be used to rebind to internal services.

Why it matters: Protect internal services from browser-based rebinding attacks.

Story 3: SSRF Prevention Validation

Imagine you're an application security engineer. Validate that your SSRF protection correctly blocks DNS (Domain Name System) rebinding — test domains should not resolve to private IPs even with low TTLs.

Why it matters: Verify SSRF defenses against DNS-based bypasses before deployment.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the DNS Rebinding Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

If you can see yourself in even one of those bullets, the DNS Rebinding Check tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the DNS Rebinding Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the DNS Rebinding Check tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with DNS Rebinding Check. If you're already running this check, the related ones often answer the next question that comes up:

• DNS Lookup — Query any of 22 DNS record types or ALL at once with DNSSEC validation

• Zone Transfer Check — Test for DNS zone transfer vulnerability

• Wildcard DNS — Detect wildcard DNS configuration

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check DNS Rebinding Check and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

IP (Internet Protocol address) — A unique number that identifies a computer on the internet, like a phone number for a server.

IPv6 (Internet Protocol version 6) — The newer, longer kind of internet address. Looks like 2001:0db8:85a3::8a2e:0370:7334. Designed because the world ran out of IPv4 addresses.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.