DNS rebinding attacks exploit the trust internal networks place in DNS, allowing an attacker to trick a browser into making requests to internal services that it shouldn’t be able to reach.
Imagine a user visits a malicious website. This website’s DNS server responds with a DNS record for a domain controlled by the attacker, but the IP address points to an internal service (e.g., 192.168.1.100). The browser, seeing a private IP, might then be instructed by JavaScript on the malicious page to make a request to this internal service. This is the initial "bind."
Then, the attacker’s DNS server immediately responds to another DNS query for the same domain with a different IP address – this time, the attacker’s public IP address. The browser, having already established a connection to the internal IP, is now tricked into sending subsequent requests to the attacker’s public IP, but the attacker can then relay these requests to the internal service, bypassing network security. The key is the browser’s short-term caching of DNS records and its trust in resolving private IP addresses.
How to Prevent DNS Rebinding
The most robust defense is to configure your DNS server to reject or ignore DNS queries for internal IP address ranges that originate from external networks. This prevents the initial "bind" from ever succeeding.
1. Configure Your DNS Server (e.g., BIND, Unbound, dnsmasq)
Most modern DNS servers have settings to restrict what they will resolve.
For BIND:
You can use allow-query and recursion yes; in your named.conf.options to define which networks are allowed to query your DNS server and whether it will perform recursion. Crucially, you can also use allow-recursion to specify which clients are allowed to use your server for recursive lookups (i.e., resolving external domains). If an external client tries to query your internal DNS server, and that server is configured to not perform recursion for them, it won’t be able to resolve the attacker’s domain to an internal IP.
A more direct approach for preventing rebinding on BIND is to use dnssec-enable yes; and dnssec-validation auto; along with ensuring your authoritative zones for internal domains are properly configured and signed. However, the most common and effective method is to block external recursive queries.
options {
directory "/var/cache/bind";
recursion yes;
allow-query { 192.168.0.0/16; 10.0.0.0/8; }; // Allow internal networks
allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; // Allow internal networks to recurse
// No allow-recursion for external IPs
dnssec-enable yes;
dnssec-validation auto;
listen-on { 192.168.1.1; }; // Listen only on internal interface
};
Why it works: This configuration explicitly states that only clients from your internal IP ranges (192.168.0.0/16 and 10.0.0.0/8) are permitted to ask your DNS server to resolve external domain names (perform recursion). If a malicious website tries to query your DNS server from the public internet, it will be denied recursive resolution, and thus cannot trick your server into returning an internal IP for a domain it controls.
For Unbound:
Unbound has a similar directive called access-control.
server:
interface: 192.168.1.1
access-control: 127.0.0.1/8 allow
access-control: 192.168.0.0/16 allow
access-control: 10.0.0.0/8 allow
access-control: ::1/128 allow
access-control: ::ffff:127.0.0.1/128 allow
# Deny all other access for recursion
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
harden-dnssec-stripped: yes
use-caps-for-id: yes
Why it works: This explicitly permits recursive queries from your internal networks. By refusing all other access (0.0.0.0/0 refuse), it prevents any external IP address from using your Unbound server to resolve domains, thus stopping the attacker’s DNS server from returning an internal IP to a browser that’s already connected to the attacker’s site.
For dnsmasq:
dnsmasq is often used on routers or smaller networks. You can control which interfaces it listens on and restrict DNS queries.
# In /etc/dnsmasq.conf or a file in /etc/dnsmasq.d/
listen-address=127.0.0.1,192.168.1.1
bind-interfaces
domain-needed
bogus-priv
domain-needed tells dnsmasq not to return an IP address for a name that has no dots. bogus-priv tells it not to return internal IP addresses for external names.
Why it works: domain-needed and bogus-priv are specifically designed to combat DNS rebinding. bogus-priv prevents dnsmasq from resolving a query for a public domain name into a private IP address (like 192.168.x.x), which is the core mechanism of a DNS rebinding attack.
2. Host-Based Firewalls and Browser Extensions
While less comprehensive, these can add layers of defense.
-
Host Firewall: Configure the firewall on your internal servers to only accept connections from specific internal IP addresses or subnets. This doesn’t stop the DNS lookup but prevents the malicious request from reaching the service.
- Example (iptables on Linux):
Why it works: This explicitly allows TCP traffic on port 80 (HTTP) only from your internal network (iptables -A INPUT -i eth0 -s 192.168.0.0/16 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 80 -j DROP192.168.0.0/16) to reach the server. Any other traffic on port 80 will be dropped.
- Example (iptables on Linux):
-
Browser Extensions: There are browser extensions designed to detect and block DNS rebinding attempts by checking DNS responses against a known list of private IP ranges and refusing to resolve suspicious queries. Examples include "NoRebind" or similar privacy-focused extensions.
Why it works: These extensions act as a client-side filter, intercepting DNS responses before the browser attempts to connect to the IP address, and blocking those that appear to be part of a rebinding attack.
3. DNS Server Response Policy Zones (RPZ)
Advanced DNS servers can use RPZ to define specific actions for certain DNS queries. You can create RPZ rules to block resolutions that match the pattern of a DNS rebinding attack.
Why it works: RPZ allows for granular control over DNS resolution. You can define a policy that says, "If a query for attacker.com returns an IP in the 192.168.x.x range, do not resolve it (or resolve it to a sinkhole IP)."
The next problem you’ll likely encounter is needing to configure your firewall to block outbound DNS requests to untrusted external DNS servers, as attackers can also use compromised external DNS servers to target your internal network.