DNS Rebinding Prevention: Protecting CDN Origin Servers

Your CDN provides DDoS protection, WAF rules, rate limiting, and bot detection — but only for traffic that flows through it. DNS rebinding attacks bypass the CDN entirely by redirecting browser requests directly to your origin server's IP address. The attack exploits the time gap between DNS resolution and HTTP request execution, allowing an attacker-controlled domain to make same-origin requests to your infrastructure. If your origin server accepts connections from any source, every CDN-layer protection becomes irrelevant. For foundational origin protection concepts, see CDN Origin Server Configuration.

How DNS Rebinding Works

The attack unfolds in four phases. First, the attacker registers a domain (say, attacker.example) and configures its DNS with a very short TTL — typically 0 or 1 second. The initial DNS response points to the attacker's own server. Second, the victim visits a page on attacker.example, and their browser loads JavaScript from the attacker's server. Third, after the DNS TTL expires, the attacker changes the DNS record for attacker.example to point to the victim's origin server IP. Fourth, the attacker's JavaScript makes requests to attacker.example — still considered same-origin by the browser — but these requests now reach the victim's origin server because the DNS has rebinded to a new IP.

The consequence for CDN-protected sites is severe. All traffic from the rebinding attack arrives at the origin server without passing through the CDN. WAF rules, DDoS protection, rate limiting, bot detection, and geographic restrictions are bypassed. If the origin server's IP address is exposed and it accepts connections from any source, the attacker has unrestricted access to the origin's HTTP services.

How Origin IPs Get Exposed

DNS rebinding requires the attacker to know your origin server's IP address. CDNs proxy DNS queries so that public DNS lookups return CDN edge IPs, not origin IPs. However, origin IPs leak through many channels that CDN configuration alone cannot close.

Historical DNS records are the most common source of origin IP leaks. Services like SecurityTrails, ViewDNS, and Shodan archive DNS records over time. If your domain pointed directly to your origin IP before you enabled CDN proxying, that historical record is permanently available. Email headers from your domain's mail server may include the origin IP in Received headers. Outbound connections from your origin server (webhooks, API calls to third-party services) reveal the source IP to the receiving server. Misconfigured subdomains that bypass the CDN — a mail.example.com or staging.example.com that points directly to the origin — expose the same IP that your CDN-proxied domains use.

Defense Layer 1: Host Header Validation

Host header validation is the single most effective defense against DNS rebinding at the origin server. In a rebinding attack, the browser sends the Host header of the attacker's domain, not your legitimate domain. If your origin server only responds to requests with recognized Host headers, rebinding requests are rejected before they reach your application logic.

# Nginx — reject requests with unrecognized Host headers
# Default server block catches everything not matched by named blocks
server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;

    ssl_certificate     /etc/nginx/ssl/default.crt;
    ssl_certificate_key /etc/nginx/ssl/default.key;

    # Return 444 (connection closed with no response)
    return 444;
}

# Only serve content for recognized domains
server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # Application configuration...
    root /var/www/example;
}

# Apache — Host header validation
<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    # Application configuration...
</VirtualHost>

# Default virtual host rejects unrecognized hosts
<VirtualHost _default_:443>
    ServerName invalid
    RewriteEngine On
    RewriteRule ^ - [F,L]
</VirtualHost>

The Nginx return 444 directive is particularly effective because it closes the TCP connection without sending any HTTP response, revealing no information about the server software or configuration to the attacker. Ensure the default server block is defined before any named server blocks in your configuration, as Nginx uses the first server block as the default if no explicit default_server is specified.

Defense Layer 2: CDN-Only Origin Access

Restrict your origin server's firewall to accept inbound connections only from your CDN provider's IP ranges. If the origin server drops all connections that do not originate from CDN edge IPs, DNS rebinding requests from browsers (which come from the user's IP, not the CDN's) are blocked at the network layer before reaching the web server.

# iptables — allow only Cloudflare IPs to reach port 443
# Cloudflare IPv4 ranges (verify current list at cloudflare.com/ips)
iptables -A INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 103.22.200.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 103.31.4.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 141.101.64.0/18 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 108.162.192.0/18 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 190.93.240.0/20 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 188.114.96.0/20 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 197.234.240.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 198.41.128.0/17 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 162.158.0.0/15 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 104.16.0.0/13 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 104.24.0.0/14 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 172.64.0.0/13 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 131.0.72.0/22 -j ACCEPT

# Drop everything else on 443
iptables -A INPUT -p tcp --dport 443 -j DROP

Automate the firewall rule updates because CDN providers periodically add or modify their IP ranges. Cloudflare publishes their current IP list at cloudflare.com/ips. AWS CloudFront publishes IP ranges in their ip-ranges.json file. Build a cron job that fetches the current list and updates firewall rules, with alerting if the list changes unexpectedly.

Defense Layer 3: Authenticated Origin Pulls

Authenticated origin pulls add a mutual TLS (mTLS) requirement between the CDN and your origin. The CDN presents a client certificate when connecting to your origin, and your origin verifies this certificate before accepting the connection. Browser-originated requests from DNS rebinding attacks do not have this client certificate and are rejected at the TLS handshake.

# Nginx — authenticated origin pull with Cloudflare client certificate
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # Require Cloudflare's client certificate
    ssl_client_certificate /etc/nginx/ssl/cloudflare-origin-pull-ca.pem;
    ssl_verify_client on;

    # Requests without valid client cert are rejected at TLS handshake
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

Authenticated origin pulls are the strongest defense against DNS rebinding because they operate at the TLS layer, below HTTP. The attacker cannot forge the CDN's client certificate, and the connection fails before any HTTP data is exchanged. This defense is independent of Host headers, IP addresses, and DNS behavior — it works even if the attacker knows your origin IP and can craft requests with correct Host headers.

Defense Layer 4: DNS Rebinding Detection in Edge Workers

If your CDN edge workers make outbound fetch requests, they need their own DNS rebinding protection. An attacker can submit a URL to your edge function that initially resolves to a legitimate IP but rebinds to an internal IP after the first request. Validate all resolved IP addresses against a blocklist of private and reserved ranges before initiating the connection.

// Edge worker DNS rebinding protection for outbound requests
const BLOCKED_RANGES = [
  { start: '10.0.0.0', end: '10.255.255.255' },
  { start: '172.16.0.0', end: '172.31.255.255' },
  { start: '192.168.0.0', end: '192.168.255.255' },
  { start: '127.0.0.0', end: '127.255.255.255' },
  { start: '169.254.0.0', end: '169.254.255.255' },
  { start: '0.0.0.0', end: '0.255.255.255' },
];

function ipToInt(ip) {
  return ip.split('.').reduce((acc, octet) => (acc << 8) + parseInt(octet), 0) >>> 0;
}

function isPrivateIP(ip) {
  const ipInt = ipToInt(ip);
  return BLOCKED_RANGES.some(range =>
    ipInt >= ipToInt(range.start) && ipInt <= ipToInt(range.end)
  );
}

async function safeFetch(url, options) {
  const hostname = new URL(url).hostname;

  // Resolve DNS and check the IP
  const resolved = await dns.resolve(hostname);
  if (resolved.some(ip => isPrivateIP(ip))) {
    throw new Error(`DNS rebinding detected: ${hostname} resolves to private IP`);
  }

  // Pin the resolved IP for this request to prevent TOCTOU race
  return fetch(url, {
    ...options,
    cf: { resolveOverride: resolved[0] }
  });
}

The time-of-check-to-time-of-use (TOCTOU) race condition is critical here. Between the DNS resolution check and the actual HTTP connection, the attacker could rebind the DNS. Pin the resolved IP address for the actual connection to eliminate this window. Some CDN platforms provide built-in resolution pinning, while others require you to use explicit IP connection instead of hostname-based connection after validation.

Layered Defense Strategy

No single defense is sufficient against DNS rebinding. Host header validation fails if the attacker discovers your real hostname and crafts the Host header accordingly. IP-based firewalls fail if the attacker routes traffic through a compromised CDN customer on the same provider. Authenticated origin pulls fail if the CDN provider's client certificate is compromised. Layer all four defenses to ensure that multiple independent mechanisms must be bypassed for an attack to succeed.

Regularly audit your origin server's exposure. Scan for direct-access paths that bypass the CDN using tools that check historical DNS records, email header leakage, and misconfigured subdomains. Verify that your firewall rules are current and that all inbound connections on HTTP/HTTPS ports originate from your CDN provider. Test your Host header validation by making requests with unexpected Host values and confirming they are rejected. For comprehensive origin server hardening, combine these DNS rebinding defenses with the broader origin protection strategies including origin cloaking, connection encryption, and zero trust architecture.