DNS Rebinding Vulnerability
Network security weakness enabling browser-based internal network attacks
Critical Security Risk
Your network infrastructure is vulnerable to DNS rebinding attacks that exploit browser same-origin policy bypasses. Attackers can use malicious websites to access internal network devices and services that should be protected by network segmentation.
Understanding DNS Rebinding Attacks
DNS rebinding attacks represent one of the most insidious threats to network security because they weaponize the very browsers that users trust to access the internet. These attacks exploit fundamental assumptions about how DNS names relate to network access, allowing external attackers to bypass firewalls, VPNs, and network segmentation through legitimate user browsers.
The attack works by manipulating DNS resolution timing to trick browsers into treating external and internal resources as the same origin. When a user visits a malicious website, JavaScript code can dynamically change DNS records to point the same domain name from an external server to internal IP addresses. The browser, seeing the same domain name, allows the malicious code to access internal resources that should be completely isolated from the internet.
How DNS Rebinding Bypasses Security:
Same-origin policy exploitation occurs when attackers change DNS records after initial page load, causing browsers to treat internal network resources as having the same origin as the external malicious site.
Network segmentation bypass happens when internal devices and services become accessible through user browsers, even when they're protected by firewalls and network access controls.
Credential and data theft becomes possible when attackers access internal web interfaces, APIs, and services that rely on network isolation rather than strong authentication for security.
Immediate Defense Actions
Understanding how these attacks exploit browser behavior makes implementing effective defenses critical for network security. Given the sophisticated nature of DNS rebinding attacks, defense requires a multi-layered approach targeting both the DNS infrastructure and application security.
Understanding how these attacks exploit browser behavior makes implementing effective defenses critical for network security. Given the sophisticated nature of DNS rebinding attacks, defense requires a multi-layered approach targeting both the DNS infrastructure and application security. Start by implementing DNS rebinding protection at your network's DNS resolver level, which provides the most comprehensive defense against these attacks. Configure your internal DNS servers to refuse responses that would redirect external domain queries to internal IP address ranges. This prevents the core mechanism that attackers use to bypass network segmentation.
Audit all internal web services and applications to ensure they don't rely solely on network location for security. Implement proper authentication and authorization controls for all internal services, even those that seem protected by firewalls. Many DNS rebinding attacks succeed because internal services assume that if a request comes from the internal network, it must be legitimate.
Critical Actions:
- ๐ก๏ธ Configure DNS resolver to block private IP responses
- ๐ Implement authentication on all internal web services
- ๐ Audit Host header validation in web applications
- ๐ง Review and strengthen network segmentation
- โ๏ธ Configure internal services to bind to specific interfaces
DNS Rebinding Protection Implementation
With defensive strategies established, implementing these protections requires DNS server configuration changes tailored to your specific platform. The theoretical defenses must now be translated into practical DNS server configurations. Each DNS platform offers different mechanisms for implementing rebinding protection, but all focus on preventing external domains from resolving to internal network addresses.
BIND Protection Configuration
Configure BIND to block private IP responses in /etc/bind/named.conf:
// Access Control List - define private/internal IP ranges to block
acl "private-addresses" {
10.0.0.0/8; // RFC 1918 Class A private networks
172.16.0.0/12; // RFC 1918 Class B private networks
192.168.0.0/16; // RFC 1918 Class C private networks
127.0.0.0/8; // IPv4 loopback addresses
169.254.0.0/16; // IPv4 link-local addresses (APIPA)
::1/128; // IPv6 loopback address
fc00::/7; // IPv6 unique local addresses (private)
};
options {
blackhole { private-addresses; }; // Block queries to private IP ranges
dnssec-validation auto; // Enable DNSSEC validation to prevent spoofing
rate-limit { // Prevent DNS amplification attacks
responses-per-second 10; // Limit responses per client per second
referrals-per-second 5; // Limit referrals per client per second
window 5; // Time window for rate limiting
log-only no; // Actually enforce limits (not just log)
};
};Critical Protection: The blackhole configuration prevents DNS rebinding by blocking queries that resolve to private networks, stopping attackers from bypassing firewalls.
Unbound Protection
Configure private address blocking in /etc/unbound/unbound.conf:
# Unbound DNS Rebinding Protection Configuration (unbound.conf)
server:
# Block private address ranges - prevent DNS rebinding to internal networks
private-address: 10.0.0.0/8 # RFC 1918 Class A private networks (10.x.x.x)
private-address: 172.16.0.0/12 # RFC 1918 Class B private networks (172.16-31.x.x)
private-address: 192.168.0.0/16 # RFC 1918 Class C private networks (192.168.x.x)
private-address: 169.254.0.0/16 # IPv4 link-local addresses (APIPA/auto-configuration)
private-address: 127.0.0.0/8 # IPv4 loopback range (127.x.x.x)
private-address: fc00::/7 # IPv6 unique local addresses (private IPv6)
private-address: ::1/128 # IPv6 loopback address
# Additional rebinding protection - block localhost queries
do-not-query-localhost: yes # Prevent queries to localhost/127.0.0.1
do-not-query-address: 127.0.0.1 # Block specific localhost queries
do-not-query-address: ::1 # Block IPv6 localhost queries
# Prevent DNS rebinding to local domains - block internal TLDs
private-domain: "local." # Block .local domain queries (mDNS/Bonjour)
private-domain: "internal." # Block .internal domain queries (common internal TLD)
private-domain: "lan." # Block .lan domain queries (router default)
local-zone: "localhost." static # Static response for localhost queries
local-data: "localhost. A 127.0.0.1" # Return fixed localhost response
# Security hardening against information disclosure
hide-identity: yes # Don't reveal Unbound version in queries
hide-version: yes # Don't reveal server software version
use-caps-for-id: yes # Use 0x20 encoded random bits (prevents poisoning)
# Rate limiting to prevent abuse
ratelimit: 1000 # Maximum queries per second per client IP
unwanted-reply-threshold: 10000 # Block unusual response patterns (security)PowerDNS Protection
Configure PowerDNS Recursor to prevent rebinding in /etc/powerdns/recursor.conf:
# PowerDNS Recursor DNS Rebinding Protection (recursor.conf)
# Block private network queries - comprehensive rebinding prevention
dont-query=127.0.0.0/8,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,192.168.0.0/16,172.16.0.0/12,::1/128,fc00::/7,fe80::/10
# 127.0.0.0/8: IPv4 loopback addresses (prevent localhost rebinding)
# 10.0.0.0/8: RFC 1918 Class A private networks
# 100.64.0.0/10: RFC 6598 Carrier Grade NAT addresses
# 169.254.0.0/16: IPv4 link-local addresses (APIPA)
# 192.168.0.0/16: RFC 1918 Class C private networks
# 172.16.0.0/12: RFC 1918 Class B private networks
# ::1/128: IPv6 loopback address
# fc00::/7: IPv6 unique local addresses (private)
# fe80::/10: IPv6 link-local addresses
# Cache poisoning prevention - detect DNS spoofing attempts
spoof-nearmiss-max=20 # Maximum near-miss responses before blocking
spoof-threshold=100 # Threshold for suspicious query patterns
lowercase-outgoing=yes # Normalize outgoing queries (security)
# Security monitoring and logging configuration
log-common-errors=yes # Log DNS errors and anomalies for analysis
loglevel=3 # Detailed logging (1=minimal, 6=verbose)
log-queries=yes # Log all queries for security monitoring
query-logging=yes # Enable comprehensive query logging
# Rate limiting and connection management
max-tcp-clients=1000 # Maximum concurrent TCP connections
tcp-fast-open=yes # Enable TCP Fast Open (performance)
client-tcp-timeout=30 # TCP connection timeout (seconds)
max-cache-entries=1000000 # Maximum cache entries (memory limit)
# Additional security hardening
security-poll-suffix= # Disable security polling (reduces attack surface)
version-string=PowerDNS Recursor # Generic version string (hide specific version)
max-qperq=60
max-total-msec=7000
# Security headers
security-poll-suffix=''Cloudflare Gateway Rules
Use Cloudflare Gateway to block DNS rebinding attempts:
- โข Navigate to Zero Trust โ Gateway โ DNS Policies
- โข Create policy: "Block Private IP Queries"
- โข Add rule for private IP ranges in DNS queries
- โข Enable logging for security monitoring
Example DNS policy configuration:
Policy Name: Block DNS Rebinding
Selector: DNS Domain
Operator: matches regex
Value: .*(10|172|192)\..*\.(local|internal)$
Action: Block
Log: EnabledApplication-Level Protection
Beyond DNS-level controls, implement Host header validation in web applications to prevent rebinding attacks that bypass DNS protections.
# Apache .htaccess protection
RewriteEngine On
RewriteCond %{HTTP_HOST} !^(www.)?yourdomain.com$ [NC]
RewriteCond %{HTTP_HOST} !=localhost
RewriteRule ^(.*)$ - [F,L]
# Nginx configuration
server {
if ($host !~* ^(www.)?yourdomain.com$) {
return 444;
}
}Building Comprehensive DNS Rebinding Defense
Effective protection against DNS rebinding requires defense in depth across multiple layers of your infrastructure. Beyond DNS-level protections, implement application-level security controls that validate Host headers, require authentication for sensitive operations, and properly handle cross-origin requests. Network segmentation should be enhanced with proper firewall rules and monitoring.
Develop organizational policies that address DNS rebinding risks in development practices, procurement of IoT devices, and network architecture decisions. Regular security assessments should include DNS rebinding vulnerability testing to ensure your defenses remain effective as your infrastructure evolves and new attack techniques emerge.
Last updated: July 25, 2025
