Cybersecurity glossary
What is DNS Rebinding?
Learn what DNS rebinding is, how attackers change DNS answers to make browsers treat internal devices as same-origin, and which defenses protect local services and private networks.
Definition
DNS rebinding is an attack technique in which a malicious hostname initially resolves to an attacker-controlled address and later resolves to a different address—often an internal or loopback IP—so a victim’s browser treats interactions with that target as same-origin with the attacker’s site.
Why DNS rebinding matters
Same-origin policy is built around scheme, host, and port—not around a permanent IP address. DNS rebinding abuses that gap. An attacker controls evil.example, serves malicious JavaScript first from a public server, then changes DNS so the same hostname resolves to 127.0.0.1 or an intranet address. The script can then interact with the internal target under the attacker’s origin name.
This technique is especially relevant for home routers, developer tools bound to localhost, and IoT devices that expose unauthenticated HTTP APIs.
How DNS rebinding works
Victim loads attacker page
The browser resolves the attacker hostname to a public IP and downloads hostile JavaScript.
Short TTL forces refresh
DNS answers expire quickly so the stub resolver must look up the name again.
DNS answer switches
The attacker’s authoritative DNS now returns a loopback or private IP for the same name.
Script calls the rebound host
Same-origin requests go to the internal service because the hostname matches.
Internal action or data access
The browser reaches the local/intranet API that assumed it was only locally reachable.
Exfiltrate results
Data can be sent back to the attacker once the hostname is rebound again or via other channels.
Typical targets
Localhost admin UIs
Developer dashboards and database UIs accidentally exposed without auth on 127.0.0.1.
Home gateways
Router management interfaces reachable from LAN clients via the victim browser.
IoT and printers
Devices with weak or no authentication on private HTTP endpoints.
Cloud metadata misuse
In some environments, host-local metadata services become interesting if reachable and weakly guarded.
Defenses by layer
| Layer | Helpful controls |
|---|---|
| Browser / client | Private network access restrictions, DNS pinning behaviors, blocking public names to private IPs |
| DNS resolvers | Response policies that prevent external names from resolving to disallowed internal ranges |
| Local services | Mandatory auth, Host header allowlists, localhost-only binds, disabling dangerous APIs |
| Network | Segmentation so browsers on user machines cannot reach sensitive management planes |
Practical checklist
- Require authentication on every local and LAN management interface.
- Validate Host headers and reject unexpected hostnames on sensitive services.
- Avoid exposing admin APIs on 0.0.0.0 when localhost binding is sufficient.
- Prefer HTTPS with valid local identity where practical; do not rely on obscurity.
- Use resolver policies to block external domains resolving to RFC1918/loopback where supported.
- Treat 'accessible only on the LAN' as insufficient authorization.
- Review developer tools and containers that publish ports to the host by default.
- Educate internal app owners that browser-based access equals cross-site risk.
The practical takeaway
DNS rebinding changes the IP behind an attacker-controlled hostname so browsers interact with internal services under a hostile origin. It is a bridge between web attackers and private network targets.
Defend in layers: harden local services with real authentication, constrain DNS answers, and rely on modern browser private-network protections where available. Anything that trusts “it came from the user’s machine” without auth is a candidate victim.
Related security terms
Same-Origin Policy (SOP)
The browser rule attackers attempt to undermine by switching the IP behind a hostname.
Domain Name System (DNS)
The resolution system whose answers are manipulated during rebinding.
Server-Side Request Forgery (SSRF)
A related class that reaches internal resources from the server rather than the browser.
DNS Spoofing / Cache Poisoning
A different DNS integrity attack that forges answers in resolvers or on-path.
Frequently asked questions
What is DNS rebinding in simple terms?
DNS rebinding tricks a browser into believing an internal device shares the attacker’s website origin. The hostname stays the same while DNS later points it at a private IP, bypassing some same-origin expectations.
What can DNS rebinding attack?
Localhost admin panels, routers, IoT devices, cloud metadata endpoints reachable from the victim host, and intranet applications that trust browser requests from 'local' users.
Does HTTPS stop DNS rebinding?
HTTPS helps when certificates do not match the rebound target, but many local devices use HTTP or accept weak TLS. Additional defenses are still required.
How do modern browsers mitigate rebinding?
Browsers and resolvers may block resolution of private IP ranges for public hostnames, cache DNS more strictly, or apply additional network isolation checks. Coverage is not universal across all clients.
How should local services defend themselves?
Require authentication, bind to localhost carefully, reject unexpected Host headers, prefer secure cookies, and avoid assuming that requests from the local machine are benign.
Is DNS rebinding the same as DNS spoofing?
No. Spoofing/poisoning forges DNS answers for victims broadly. Rebinding typically uses an attacker-operated authoritative DNS that intentionally changes answers over time for its own domain.
What DNS TTL tricks are used?
Attackers often set very short TTLs so browsers or stub resolvers re-query quickly and receive a new IP pointing at the internal target.
References
Explore authoritative guidance and frameworks related to dns rebinding.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.