DNS Rebinding: Protect Local Services From Changed Answers

A local gateway’s management page may be reachable only from an internal network, yet a user on that network also visits external websites. A change in a domain’s DNS answer can make that browser reach a local service under an external name. Protecting against this rebinding of DNS answers requires controls at the service, browser, and network boundaries.

Where trust crosses a boundary

In a DNS rebinding scenario, an externally controlled hostname can first resolve to an external address and later to an internal or loopback address. The browser’s origin is based on the URL’s scheme, hostname, and port, rather than the resolved IP address. If a subsequent connection reaches a local service under the same origin and that service accepts the request, a page may interact with a resource the site’s operator could not reach directly. The outcome depends on browser behavior, protocols, reachability, and the service’s own controls.

A DNS-based rebinding attempt exploits an assumption that a name continues to identify the same destination. The vulnerable assumption is often in the local service: it treats requests as trusted because they arrive from the local network or accepts arbitrary hostnames without authenticating the user. A changed DNS answer by itself does not grant access to a properly protected application. It can nevertheless turn a user’s browser into a path across a boundary that the service owner expected the network location to enforce.

MDN’s same-origin explanation describes the scheme, host, and port used in origin checks. DNS answers can legitimately change for failover or load balancing, so an address change alone is not proof of malicious activity. This is distinct from an ordinary stale DNS cache: the security question is which component trusts the destination after resolution and what that destination permits.

Protect the service first

Defenses against rebinding attacks on DNS should begin with the exposed service. Inventory gateway interfaces and other local web services, including administration APIs. Restrict which network interfaces and management segments can reach them, and disable services that are not needed. Require authentication and authorization for sensitive actions even when the request comes from a local address. Use supported software, remove default credentials, and apply updates through the organization’s maintenance process.

Configure each service or its reverse proxy to accept only its expected hostnames, rejecting unexpected Host values. Use authenticated HTTPS with valid certificates where supported, and enforce appropriate request-origin and cross-site request protections for browser-facing functions. Host validation is one layer: headers can be supplied by non-browser clients, so it does not replace authentication or network restrictions.

DNS rebinding defenses can also include resolver policies that reject suspicious public-name answers pointing to internal addresses. Such rules need carefully managed exceptions for legitimate split-DNS and internal services. Browser local-network protections may add another layer, but their behavior and deployment vary; verify the versions and policies used by the organization.

Address server-side requests too

A server that fetches a user-supplied URL faces a related trust problem. A hostname may pass an initial check and resolve differently before a connection is made. For applications that allow outbound requests, validate destination addresses against the intended policy and ensure the connection uses a validated address, including on redirects and retries. Maintain normal hostname and certificate verification for TLS. OWASP’s SSRF prevention guidance describes why checking a name separately from the actual connection is insufficient.

Verify protection and compatibility

In an authorized test environment, inventory expected management names and workflows, then confirm that unexpected hostnames and unauthenticated requests are rejected. Test DNS rebinding protection alongside legitimate internal DNS, remote management, and application access using the supported browser and resolver configuration. Review logs for rejected requests and resolution-policy events, and assign an owner for exceptions.

After changes, repeat the checks from representative user and management segments. Confirm that authorized administrators can still reach the correct service, that unauthorized paths remain blocked, and that alerts reach the team responsible for the gateway. Record the configuration and retest after browser, resolver, or device updates.