Fast-flux vs CDN: how to tell them apart

Fast-flux DNS is the practice of keeping a domain's IP set rotating constantly — sometimes every few seconds — across a botnet of compromised endpoints. A normal website changes IPs a few times a year when it migrates hosting; a fast-flux domain changes IPs hundreds of times per day. The technique was first observed in the early 2000s by spam operators (ICANN SAC 025, 2008), is catalogued as MITRE ATT&CK T1568.001, and remains the backbone of modern phishing, malware command-and-control, and credential-theft infrastructure.

The technique works because static threat feeds (Spamhaus DBL, Google Safe Browsing, PhishTank, etc.) have a characteristic delay — anywhere from a few hours to a few days — between when an attacker spins up infrastructure and when the IPs land in the feed. By rotating IPs faster than the feeds update, fast-flux operators stay ahead of the blocklist. Every individual IP gets blocked eventually, but by then the campaign has moved to a new set.

Behavioral detection — watching TTL, rotation, and network-spread signals over time — closes that gap. Done well, behavioral detection catches the campaign while it's still live, which is when blocking actually prevents harm.

The hard problem in fast-flux detection isn't catching the rotation — it's distinguishing botnet rotation from CDN rotation, because at the surface they're identical:

• Both rotate IPs.

• Both use short TTLs.

• Both serve different addresses to different users.

• Both can return many IPs in a single response.

A naive fast-flux detector — one that just flags any domain with TTL <300s and multiple A records — produces a torrent of false positives on every site behind Cloudflare, Akamai, Fastly, AWS CloudFront, Google Cloud Load Balancer, or any other CDN. Operators who deploy such tooling learn to ignore the alerts within a week. This is the underlying reason fast-flux detection has a reputation for being unreliable: most production tools optimize for catching the bad case and underweight the cost of false positives, which makes the alerts useless.

The signals that actually distinguish the two are structural, not behavioral. Behavioral signals (TTL, rotation count, IP-set churn) are necessary but not sufficient. Structural signals (which networks the IPs sit in) are what carry the discriminating power.

Every IP on the internet belongs to an Autonomous System (AS), identified by an ASN (AS number). CDNs are large but architecturally simple: Cloudflare is mostly AS 13335, Fastly is AS 54113, Akamai is a small set of ASNs, AWS CloudFront is AS 16509 and AS 14618. When a CDN rotates IPs across its anycast network, the rotation happens within a small handful of ASNs.

Fast-flux is structurally different. The hosts are compromised consumer endpoints — home PCs, badly-configured cloud VMs, IoT devices — scattered across many residential ISPs. A typical fast-flux campaign rotates across 10 to 100+ ASNs. The structural signal is the Holz et al. AS-fraction metric:

``` asn_diversity = (unique_ASNs - 1) / max(1, unique_IPs - 1) ```

The value ranges from 0 (every IP shares one AS) to 1 (every IP in a different AS). Concrete intuition:

• Cloudflare-hosted domain: 50 IPs, 1 ASN → ratio 0.0

• Multi-cloud high-availability site: 8 IPs, 3 ASNs → ratio 0.29

• Typical fast-flux domain: 12 IPs, 11 ASNs → ratio 0.91

The response surfaces `asn_diversity_ratio` directly, alongside `unique_asns` and `unique_countries`. Confidence scoring uses these as gating signals: high-confidence fast-flux requires ≥ 3 unique ASNs and a diversity ratio ≥ 0.5.

An obvious next move after "check ASN diversity" is "keep a list of known CDN ASNs and downgrade verdicts when the rotation lives entirely inside that list." The endpoint does exactly this. The internal allowlist contains the primary edge ASNs of the major CDNs — Cloudflare, Fastly, Akamai, CloudFront, Azure CDN, Google CDN, Imperva, StackPath, BunnyCDN, EdgeCast, Limelight, and more — and a domain whose rotated IPs sit predominantly inside this set is classified as `is_cdn_rotation: true` rather than fast-flux.

The reason this isn't sufficient on its own is twofold:

1. The allowlist is conservative by necessity. Cloud providers (AWS EC2, Google Cloud Compute Engine, DigitalOcean, Hetzner) host both legitimate sites and malware. Their ASNs aren't on the allowlist because adding them would whitelist actual fast-flux campaigns running on cloud VMs. So a domain whose IPs sit on AWS EC2 might have low ASN diversity but still be malicious. 2. Sophisticated operators imitate CDN structure. A fast-flux operator who concentrates infrastructure inside a single VPS provider gets a lower AS-fraction than the textbook signature. The allowlist doesn't help against a campaign deliberately running on a single AS.

The answer is to combine signals — ASN diversity + CDN allowlist + reverse-PTR pattern + NS rotation — so that no single dimension carries the verdict alone.

Reverse DNS (PTR records) is the missing structural signal. Compromised consumer endpoints almost always have residential-ISP PTRs — names with patterns like `.dyn.`, `.dynamic.`, `.cable.`, `.broadband.`, `.dsl.`, `.adsl.`, `.fios.`, `-static-cable.`, `.dhcp.`. CDN edge IPs and legitimate datacenter infrastructure use stable names without these patterns.

The response includes `ip_asn_detail[]` with a `ptr` field per IP and an `is_residential_isp` boolean derived from a pattern match. The aggregate `residential_isp_ip_count` tells you how many of the rotated IPs match. Two or more is a strong indicator that you're looking at a botnet, even when ASN diversity alone might be ambiguous.

This is also the cheapest signal to apply: PTR queries are free, and the pattern set is small. There's no good reason a modern fast-flux check shouldn't use it.

Standard fast-flux rotates the A records — every query returns a new set of IPs. The authoritative nameservers themselves stay stable, hosted at a relatively normal-looking domain. This is single-flux, and it's the common case.

More evasive operators rotate the NS records too — every few minutes, the authoritative nameservers themselves change, sometimes pointing at compromised endpoints in the same botnet. This is double-flux, and it makes takedown dramatically harder: even if a coordinated effort reaches the registrar to suspend the parent NS records, the lookups have already moved to a new set.

The response checks for double-flux by capturing the NS RRset on every probe round. `unique_ns_count` and `ns_set_changes` quantify the rotation; `is_double_flux` is set when both signals are present and structurally consistent. Double-flux + low TTL + residential PTR is the strongest fast-flux signature available without joining a passive-DNS feed.

For escalation purposes, double-flux is roughly the difference between "likely phishing operator" and "sophisticated criminal infrastructure."

Top-down decision tree:

• `is_cdn_rotation: true` — the IPs land predominantly in known-CDN ASNs. This is a CDN, not fast-flux. Stop here unless you have specific reason to suspect the CDN is being abused.

• `is_fast_flux: true` and `confidence: "high"` — actionable. The signature is consistent with botnet hosting.

• `is_fast_flux: true` and `confidence: "medium"` — investigate, don't auto-block. Cross-reference with `domain-threat` and `ip-reputation` endpoints.

• `is_double_flux: true` — escalate. NS rotation is rarely accidental.

• `residential_isp_ip_count >= 2` — strong botnet signal regardless of other dimensions.

• `is_fast_flux: false` — no rotation observed, or rotation is explained by CDN structure.

The `confidence` field is gated on structural evidence: `high` requires 3+ ASNs and AS-fraction ≥ 0.5, OR double-flux, OR 2+ residential-PTR IPs. Without those, it caps at `medium` regardless of behavioral signals.

Different uses of the endpoint have different operational profiles:

SOC triage (alert). Run on every domain that hits a SIEM rule. `is_fast_flux: true` + `confidence: "high"` is enough to escalate an investigation; combined with `domain-threat` reputation hits, escalates to a true positive. This is the primary use case.

Protective DNS (block). A protective DNS resolver can block confidently on `is_fast_flux: true` + `confidence: "high"` + `is_double_flux: true`. Lower confidence levels should rate-limit or quarantine, not block — false positives degrade trust in the resolver.

Threat-hunting (correlate). The signals are complementary to passive-DNS feeds. A domain that's been seen rotating across many ASNs with residential PTRs is worth investigating even when threat feeds haven't named it yet — fast-flux campaigns precede feed inclusion by 1-3 days.

Brand protection (alert on shadow domains). Combine with the `domain-shadow-domains` endpoint: a typosquat that's also fast-flux is a higher-priority finding than a typosquat that's parked.

Foundational research:

• Holz et al. — Measuring and Detecting Fast-Flux Service Networks (NDSS 2008) — the canonical paper, source of the AS-fraction metric.

• ICANN SAC 025 (2008) — the first formal documentation of the technique.

• MITRE ATT&CK T1568.001 — Fast Flux DNS — adversary-behavior catalog entry.

• Palo Alto Networks Unit 42 — Fast-Flux 101 — modern overview with case studies.

Related EdgeDNS resources:

• `/v1/dns/fast-flux` — endpoint reference

• Fast-flux concept explainer — encyclopedia-style summary

• DNS Vulnerability Assessment use case — security-team-oriented narrative

• Single-call DNS health audit — composite zone-health context