DNS Rebinding Check: a beginner's guide

DNS rebinding is a class of attack where a malicious website uses DNS — specifically, the way browsers re-resolve domain names — to bypass the security boundary that normally separates the public internet from the private network behind your home router or office firewall. The attack works because of an asymmetry: browsers enforce the same-origin policy using domain names, not IP addresses. So if a website's domain initially resolves to a public IP and then later resolves to a private IP (like `192.168.1.1`, the address of your home router's admin interface), the browser still 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 at all.

You should care because DNS rebinding is the most common way attackers reach into the trusted internal network of a victim from a malicious public website. The attack is silent — the user just visits a page — and the consequences depend on what the attacker can reach: the home router admin panel, an unauthenticated IoT device, a corporate intranet, an internal API, a development server. There have been real exploited vulnerabilities of this kind in routers, smart-home hubs, cryptocurrency wallet software, and developer tools. The defense is simple but rarely implemented by default.

The five things every DNS rebinding check looks at:

• Does the resolver reject responses pointing at private IPs? A properly hardened resolver should refuse to return RFC 1918 (`10/8`, `172.16/12`, `192.168/16`) and other private-network addresses for public domain names.

• Does the application validate the destination IP, not just the hostname? Server-side defenses should resolve the hostname themselves and refuse to make outbound connections to private ranges.

• Are local services bound to localhost rather than `0.0.0.0`? Services that only listen on `127.0.0.1` cannot be reached even by a successful rebinding attack.

• Do internal services require authentication? A device that requires a password is much harder to attack via rebinding than one that doesn't.

• Are there `Host` header checks on internal HTTP services? Many rebinding attacks fail when the target service refuses requests with an unexpected `Host` header.

Three questions a DNS rebinding check answers:

• Could a malicious website I visit reach the admin interface of my home router or my IoT devices?

• Is my development environment exposing services that could be hit by a rebinding attack from the browser tab next to my coding session?

• Does my product have endpoints that an attacker could reach by tricking a victim's browser into talking to them?

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 their internal network. The fix is mostly defensive coding (binding to localhost, validating IPs, requiring auth), and the topic deserves more attention than it typically gets in security reviews. The Wikipedia page on DNS rebinding is an excellent introduction.

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:

Analyzes DNS (Domain Name System) configuration for rebinding attack indicators: very low TTLs (under 60 seconds), multiple A records with mixed internal/external IPs, and CNAME (Canonical Name record) chains that could facilitate rebinding. Checks all the official internet standard 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), cloud metadata endpoints (169.254.169.254), and the official internet standard documentation ranges (TEST-NET-1/2/3). Also detects IPv6 (Internet Protocol version 6) private addresses (::1, fc00::/7, fe80::/10) and transition mechanisms (Teredo 2001::/32, 6to4 2002::/16, NAT64 64:ff9b::/96). Provides risk assessment and mitigation recommendations.

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.

Browser mitigations like DNS (Domain Name System) pinning and Chrome's Private Network Access (PNA) provide partial protection, but server-side applications remain vulnerable. This endpoint helps identify domains configured for potential rebinding attacks against internal services, image proxies, and OAuth callbacks.

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.

CNAME (Canonical Name record) — A DNS entry that says "this name is just an alias for that other name."

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.