Fast Flux DNS

Fast flux keeps a malicious domain alive by constantly changing the IP addresses it resolves to. Instead of pointing at one server, the domain's A records are cycled — often every few minutes — across a large pool of compromised machines that act as reverse proxies, forwarding victim traffic to a hidden "mothership" backend. Sinkholing the IPs is futile because they rotate faster than abuse reports can be actioned, and the IPs themselves are innocent victims, not the operator's infrastructure.

"Single flux" rotates the A records (the host layer). "Double flux" additionally rotates the authoritative NS records, so even the nameservers answering for the zone are part of the flux pool, removing the last stable pivot. The technique underpinned major botnets (Storm Worm, the Avalanche network, Necurs) and remains a CISA-flagged resilience method for C2, phishing, and malware distribution.

How it works

The hallmark is a domain whose DNS answers carry a very short Time-To-Live and a churning set of unrelated IPs:

; Successive lookups of the same fast-flux domain, minutes apart:
flux.example.   120  IN  A  203.0.113.47     ; TTL = 120s
flux.example.   120  IN  A  198.51.100.9
flux.example.   120  IN  A  192.0.2.211

; ~3 minutes later — wholly different hosts, different ASNs/countries:
flux.example.   120  IN  A  198.51.100.77
flux.example.   120  IN  A  203.0.113.150
flux.example.   120  IN  A  192.0.2.4

The bots in the pool run a thin proxy (often a few lines of socket-forwarding code) that relays inbound connections to the mothership; the operator's authoritative server hands out a rotating subset of currently-online bots. From the implant's side there is nothing special to reverse — it just resolves the domain — so the analysis target is the DNS and infrastructure behaviour, not the binary's resolver loop.

Detection & analysis

Static analysis:

• The malware sample typically yields only the fast-flux domain (and any DGA that produces it). Recover the domain(s) and any embedded TTL/resolver behaviour; the resilience lives in the network, so static analysis mainly provides the seed domains to pivot on.
• If the sample includes the proxy/relay component itself (when you are analysing a bot from the pool rather than a victim implant), look for a minimal socket-forwarding loop and a hard-coded mothership address or callback used to register the host as an available node — that backend is the real target.

Dynamic analysis:

• Resolve the suspect domain repeatedly over time and record the answer set. Fast flux reveals itself through a combination of: very low TTL (often 0–300s), a large and changing pool of A records, and IPs scattered across many autonomous systems, geographies, and residential/ISP ranges rather than a single hosting provider.
• Passive DNS is the strongest tool: a domain whose historical A records number in the dozens or hundreds, with rapid turnover and high ASN diversity, is a textbook flux indicator. Double flux additionally shows churning NS records.
• Pivot on the proxy IPs to map the compromised pool, and correlate shared IP sets to cluster related flux domains and reach the backend.

Detection rule hint:

Score a domain for fast flux using TTL ≤ 300s, a high count of distinct resolved IPs over a short window, and high diversity of autonomous systems/countries among those IPs (e.g. >5 ASNs across the answer history). A short-TTL domain whose IPs constantly rotate across many unrelated networks is the defining signature — benign CDNs rotate too, so weight ASN diversity and residential-range membership to separate flux from legitimate load balancing.