Random hostnames

❮ Back to FAQ

If you use a partial (CNAME) zone setup, you may see hundreds of random hostnames in your HTTP request logs despite only proxying a few DNS records. This is caused by Host header manipulation attacks, not a bug in Cloudflare logging.

Attackers use a technique called Host header injection:

1. They discover the Cloudflare IP addresses serving your proxied hostname (for example, via DNS lookup of a known proxied subdomain).
2. They send HTTP requests directly to those IPs with forged Host headers containing random subdomain guesses.
3. Cloudflare logs the Host header value as-is in the ClientRequestHost field.
4. The requests reach Cloudflare because they target valid Cloudflare IPs — but the attacker controls the Host header content.

The http.host field contains the Host header from the original request, which means attacker-controlled values appear in your logs.

With partial (CNAME) zones:

• Only specific hostnames point to Cloudflare via CNAME at your authoritative DNS provider.
• Cloudflare does not control the full zone, so it cannot validate that incoming Host headers match configured records.
• Attackers can enumerate subdomains by sending requests to known-good IPs with guessed Host headers.

"ClientRequestHost","_count"
"legitimate-proxied.example.com","12498"    # Real traffic
"another-proxied.example.com","6082"        # Real traffic
"0-0.example.com","2"                       # Scanner
"admin.example.com","2"                     # Scanner
"api-staging.example.com","2"               # Scanner
"1234567890.example.com","2"                # Scanner

Create a WAF custom rule that only allows requests with valid Host headers:

Expression:
(http.host ne "proxied-hostname-1.example.com" and
 http.host ne "proxied-hostname-2.example.com" and
 http.host ne "proxied-hostname-3.example.com")

Action: Block

Yes. If you prefer cleaner logs without blocking traffic:

• At Logpush level — Filter the job to include only known-good hostnames using Logpush filters.
• At SIEM level — Filter or exclude hostnames with request counts below a threshold during log analysis.

Possibly, if the Host header happens to match a configured hostname or if you have a default or catch-all origin. Check EdgeResponseStatus and OriginResponseStatus to see if origins were contacted.

The risk is low to moderate. The main concerns are:

• Information disclosure if error pages reveal internal details.
• Resource consumption if requests reach your origin.
• Log noise that makes real attacks harder to identify.

Automated scanners typically send one to two requests per subdomain guess — one initial probe and possibly one retry. This uniform distribution is a reliable indicator of scanning activity.

After implementing a WAF rule:

1. Check Firewall Events for blocked requests matching your rule.
2. Compare log volume before and after — suspicious hostnames should disappear.
3. Verify legitimate traffic is unaffected by checking request counts for real hostnames.