DNS rebinding can let an attacker-controlled web page address a reachable internal HTTP service under the attacker’s hostname. Success depends on browser protections, resolution and connection behavior, and the target service. Opening a page does not guarantee access to every device. This article explains the boundary and defensive checks; it reports no DechoNet attack experiment.

A hostname is not a fixed endpoint

MDN’s same-origin policy reference defines an origin by scheme, host and port. The resolved IP is not part of that tuple. Cross-origin reads are generally restricted, while some requests and resource embedding remain possible. CORS is not authentication and does not prevent every request from reaching a server.

In a simplified HTTP example, a page first loads from an attacker-controlled hostname on a public IP. A later resolution of the same hostname returns an internal address. If the browser connects there with the same scheme and port and the service accepts the hostname and request, the script may address it under the same origin. Low DNS TTL alone does not guarantee a new lookup: resolver/OS caches and persistent connections also matter. For HTTPS, the target must additionally satisfy TLS validation for that hostname; ordinary internal HTTPS cannot simply be substituted for the attacker’s site.

The 2007 Stanford paper studies rebinding and DNS pinning in the browsers and plugins of its time. Its experimental scale is historical evidence, not a current browser success rate. Pinning a hostname to an address can help, but application defenses should not rely solely on cache timing.

Defenses have specific scopes

Intruder’s 2023 research, updated in 2024, describes fast rebinding involving IPv6 and A/AAAA response or connection behavior. It is not evidence that returning two IPv4 A records always works in current Chrome or Safari.

At the resolver, the dnsmasq manual documents --stop-dns-rebind for rejecting private-address replies from upstream servers. It also documents localhost and per-domain exceptions. Check the running configuration and exceptions; installing dnsmasq does not establish that protection is enabled, or that every client uses that resolver.

Oligo’s 2024 disclosure showed requests to 0.0.0.0 reaching local services on tested Linux/macOS systems even when the response was unreadable because of CORS. This is a related local-access issue and does not require a DNS change. The disclosure’s browser remediation status was time-specific; it is not proof that every current browser behaves alike.

Chrome 142 introduced Local Network Access restrictions, including permission gating for covered requests to local addresses or loopback. This permission is restricted to secure contexts. The design documentation explains the replacement of the earlier PNA effort. Scope varies by browser version and request mechanism; a permission prompt is not a substitute for service authentication.

What an internal service operator should check

  1. Require authentication and authorization even on LAN or loopback services. Protect state-changing browser requests against CSRF; rejecting response reads is insufficient.
  2. Validate the expected HTTP Host/authority rather than accepting arbitrary public hostnames. Combine this with authentication: a hostname allowlist alone does not stop all direct cross-origin requests.
  3. Keep device firmware and browsers updated, limit network reachability, and review resolver exceptions. Do not assume one browser feature covers every client.
  4. Use DNS lookup and HTTP headers only for public endpoint observations. DechoNet does not test rebinding into your LAN or certify an internal service’s authentication. For broader public-check limits, see methodology.

The practical lesson is to make the service enforce its own access boundary. Browser and resolver restrictions add layers; none should be treated as permission to expose an unauthenticated local control API.