Cloudflare Discovery

The Infracast Cloudflare plugin connects to the Cloudflare API to enumerate your DNS zones, DNS records, firewall rules, page rules, and Workers scripts. This gives you full visibility into your DNS security posture, edge traffic policies, and serverless edge deployments — all correlated with the rest of your infrastructure in the Infracast topology graph.

How It Works

1. Infracast authenticates to the Cloudflare API using an API token
2. All zones (domains) managed in the Cloudflare account are enumerated
3. For each zone, DNS records, DNSSEC status, firewall rules, and page rules are collected
4. Workers scripts deployed to the account are discovered and linked to their routes
5. Resources are normalized and written to the Infracast graph

Prerequisites

• A Cloudflare account with one or more zones
• A Cloudflare API token with read permissions (see below)

Creating a Cloudflare API Token

1. Log in to dash.cloudflare.com
2. Go to My Profile → API Tokens → Create Token
3. Start with the Read All Resources template, or create a custom token with:

Permission	Level	Purpose
Zone:Read	All zones	Enumerate zones and settings
DNS:Read	All zones	Read DNS records
Firewall Services:Read	All zones	Read firewall rules
Page Rules:Read	All zones	Read page rules
Account:Read	Account	Read account metadata
Workers Scripts:Read	Account	Read Workers scripts

4. Set Zone Resources to All zones (or restrict to specific zones)
5. Click Create Token and copy it — shown only once

tip

Use a read-only API token scoped to the minimum permissions needed. Never use your Global API Key for automated integrations — it has full account access and cannot be scoped.

Registering the Credential in Infracast

infracast creds add \
  --plugin cloudflare \
  --name "cloudflare-account" \
  --type api-token \
  --api-token-file /run/secrets/cloudflare-api-token

Configuring the Discovery Job

infracast.yaml

discovery:
  jobs:
    - name: cloudflare-discovery
      plugin: cloudflare
      credential: cloudflare-account
      schedule: "0 */6 * * *"   # every 6 hours
      config:
        # Optional: restrict to specific zone names
        # zones:
        #   - "example.com"
        #   - "example.io"
        # Discover Workers scripts (default: true)
        discover_workers: true
        # Collect DNSSEC status per zone (default: true)
        discover_dnssec: true

What Gets Discovered

Resource Type	Description
cloudflare.zone	DNS zone (domain) — includes plan, status, DNSSEC enabled/disabled, name servers, zone settings
cloudflare.dns_record	DNS record — type (A, AAAA, CNAME, MX, TXT, NS, etc.), name, content, TTL, proxied status
cloudflare.firewall_rule	Firewall rule — expression, action (block/allow/challenge/js_challenge), priority, enabled status
cloudflare.page_rule	Page rule — URL pattern, actions (redirect, cache settings, etc.), priority, status
cloudflare.worker_script	Workers script — name, modified timestamp, routes bound to the script

Graph Relationships

• cloudflare.zone → contains → cloudflare.dns_record
• cloudflare.zone → contains → cloudflare.firewall_rule
• cloudflare.zone → contains → cloudflare.page_rule
• cloudflare.worker_script → routes_to → cloudflare.zone

Use Cases

DNS Security Findings

Infracast correlates Cloudflare DNS data with the rest of your infrastructure graph to surface:

• DNSSEC disabled on production zones — increases susceptibility to DNS cache poisoning
• Dangling DNS records — CNAME or A records pointing to resources that no longer exist (subdomain takeover risk)
• Exposed internal records — DNS records resolving to RFC-1918 addresses that are publicly queryable
• Missing SPF/DKIM/DMARC — email authentication gaps on mail-sending domains
• Overly permissive SPF records (e.g., +all or very broad include chains)

Edge Policy Visibility

• Disabled firewall rules — rules that exist but are turned off
• Workers with no routes — orphaned scripts that may indicate stale deployments
• Unproxied sensitive records — A/AAAA records not behind Cloudflare's proxy (orange cloud off) exposing origin IPs

Cross-Stack Correlation

Cloudflare nodes are linked to corresponding infrastructure nodes where identifiable:

• A DNS record pointing to an AWS CloudFront distribution will be linked in the graph
• A Workers script serving a domain will be associated with backend origin nodes

Troubleshooting

403 Forbidden from Cloudflare API

Symptom: Error: 403 Forbidden — Token does not have sufficient permissions

Checks:

1. Verify the token has Zone:Read and DNS:Read at minimum
2. Check that the token's zone resource scope includes the zones you expect — it may be scoped to specific zones only
3. Tokens are invalidated if you rotate them or reach the expiry date

# Test the token manually
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "https://api.cloudflare.com/client/v4/user/tokens/verify"

Zones missing from discovery

Symptom: Some domains not appearing in Infracast

Checks:

1. Verify the token's Zone Resources scope includes all zones (not just specific ones)
2. Zones in a paused state are still discovered; zones in a deleted state are not
3. If using multiple Cloudflare accounts, create a separate connector for each account

Workers not discovered

Symptom: cloudflare.worker_script nodes absent

Checks:

1. Verify the token has Workers Scripts:Read account-level permission
2. Ensure discover_workers: true is set in the job config (it's the default)
3. Workers must be deployed to a paid zone or Workers Paid plan — Workers on free plans may not be enumerable via all API endpoints

Rate limiting

Symptom: 429 Too Many Requests in job logs

Fix: Reduce the job frequency or add rate limit config:

config:
  api_rate_limit_rps: 4   # Cloudflare free tier: ~1,200 req/5 min