Ask a resolver for a hostname twice, get two different IP addresses, and nothing is necessarily wrong. DNS legitimately returns multiple addresses, rotates them, and uses short TTLs for load balancing and failover.
Malicious fast flux hosting turns those same behaviors into an evasion layer. The name stays put while the addresses behind it churn rapidly, so the visible infrastructure rarely sits on one host long enough to pin down. It’s another example of why attackers use DNS. Attackers evade controls using ordinary DNS behavior without changing the protocol.
The name stays stable while the addresses move
An A record set maps a name to one or more IPv4 addresses, and an AAAA set does the same for IPv6. Nothing requires those sets to hold still. An authoritative server can publish several addresses for a name and change them whenever it likes, and because each cache counts down its own copy independently, different resolvers hold different address sets at the same moment.
Fast flux pushes that flexibility to the limit, with many addresses, short TTLs, and a frequently changing, often overlapping subset of a larger host pool exposed on each refresh. The authoritative data is the control point. Clients keep asking for the same name, and the answer decides which hosts the next connection can choose from.
Short TTLs shorten each cached view
A TTL sets how long a resolver treats a cached answer as fresh. Once it expires, the resolver ordinarily consults DNS again the next time the answer is needed. Short TTLs shrink that window, and a 60-second answer comes up for refresh far sooner than one holding 3,600 seconds.
That doesn’t mean every client sees a new address each minute. A client may hold an existing connection open, intermediate caches may have learned the answer at different times, and one answer can carry several addresses at once. The result is churn spread across time, not a synchronized global rotation.
service.example.com returns 192.0.2.10, 192.0.2.20, and 192.0.2.30 with a 60-second TTL. A later refresh returns 192.0.2.40, 192.0.2.50, and 192.0.2.60. A resolver still holding the first answer keeps serving it until that copy expires, while another resolver has already learned the second set.
Single flux moves the service, and double flux moves the name servers
The simpler form, single flux, keeps the service name fixed while the A or AAAA records under it change frequently. A client resolves the name, gets one group of addresses, then gets a different group after the cached answer expires, so traffic reaches many front-end systems without touching the hostname baked into a link, config file, or command channel. Historically those front ends were often compromised machines acting as proxies, relaying connections toward hidden infrastructure so the visible addresses could rotate without moving the real service.
Double flux adds a second moving layer. The DNS infrastructure serving the zone changes too, whether by rotating the addresses of the authoritative name servers or swapping the name server set itself, which puts another shifting layer between an investigator and whatever controls the domain. The Honeynet Project described the single-flux and double-flux categories in 2007, ICANN’s Security and Stability Advisory Committee documented both soon after, and MITRE ATT&CK draws the same single-versus-double distinction.
Under all the movement, the mechanisms stay completely ordinary, just delegation, address records, caching, and TTL expiration.
The same techniques run legitimate services
Multiple addresses and short TTLs aren’t attacker-only tools. Operators rotate addresses for load distribution, steer users to nearby service locations, and change answers during operational events. RFC 9199 covers TTL tradeoffs and notes that large services rotate A and AAAA answers for DNS-based load balancing. ICANN’s own fast flux working group acknowledged these legitimate uses while trying to pin down the malicious pattern.
A rule that flags every domain with several addresses and a low TTL will flag plenty of legitimate content-delivery, load-balancing, and failover setups too. The useful question is rarely whether an address changed but how the domain, address pool, TTLs, name servers, hosting networks, and connection behavior all move together over time.
Seeing fast flux takes time-series evidence
Fast flux is temporal, so a single DNS answer is one frame of a film:
service.example.com. 60 IN A 192.0.2.10
service.example.com. 60 IN A 192.0.2.20
service.example.com. 60 IN A 192.0.2.30That shows the name with three addresses and a short TTL at the moment of the query. It says nothing about whether they changed a minute ago, will change a minute from now, or belong to abusive hosts. Seeing the flux takes observation across time, from active resolution that re-queries the name, passive DNS that records what sensors saw historically, and resolver logs that show what clients actually asked and received. Each source captures a different slice, so the apparent churn depends on where you stand to watch.
Caching complicates that further, and it cuts both ways. Fast flux needs its frequent authoritative changes to actually reach observers, and caching lets resolvers reuse older answers instead. Short TTLs shrink the cache window without closing it. Two resolvers refresh at different times and expose different slices of the pool, and a resolver with a still-valid answer may not query the authoritative server during a given window at all. This is why a measurement taken straight against the authoritative server can differ from what ordinary clients see, and why an old address showing up after the authoritative data moved may be nothing more than a still-valid cached answer, though it takes timestamps and vantage point to rule out stale-serving or inconsistent authoritative views.
The churn carries more signal when the addresses also span many unrelated networks, but a genuinely distributed legitimate service does that too, so diversity is still not a verdict. MITRE’s fast flux detection guidance correlates repeated resolutions, rapid address change, low TTLs, query activity, and process context rather than trusting any one field. DNS can show how fast infrastructure changes and how widely it spreads, but it can’t establish the purpose of every host in the pool on its own.
Summary
Fast flux keeps a name stable while the infrastructure behind it changes fast, and double flux moves the name servers too. None of it is uniquely malicious, since legitimate services rotate addresses and use short TTLs for their own reasons.
The distinguishing evidence appears across time, because fast flux is a behavior pattern built from ordinary DNS mechanics, not a single response you can inspect and judge.