Fast flux rotates hundreds of addresses behind one name — what is the fixed point?

## What flux is doing A rendezvous name under fast flux behaves nothing like a normal service name. Each answer carries a small set of addresses and a time-to-live measured in a few minutes, so no answer is held anywhere for long. Ask again shortly afterwards and you get a different set, drawn from a pool that can run to thousands of hosts — usually infected consumer machines on home broadband, exactly the population the operator already owns. Those hosts are not the operator's servers. They are relays: they accept the connection and forward it to a backend that appears in no answer and is often several hops away. The consequences are the ones that matter in an interview: - Each address is **disposable**. Removing one costs the operator one throwaway node out of a very large pool, and the pool refills as new machines are compromised. - The short lifetime is not evasion for its own sake, it is **fitness**. The nodes are consumer machines that reboot, sleep, change address on their provider's schedule and drop off entirely. A short answer lifetime lets the operator keep only the currently live subset in rotation without ever leaving anyone pointed at a dead node. - Seizing a relay yields **the next hop at most**. It holds no content and typically no operator credentials. **Double flux** extends the same trick upward: the authoritative nameservers listed for the zone are themselves rotated through the pool, so the machines answering queries for the name change too. Now both the answer and the answerer are moving. ## The part that cannot move Run the layers upward and you find exactly one that does not rotate. The addresses move. Under double flux the nameservers move. But the *delegation* of the name — the record in the parent zone that says which nameservers are authoritative for it, and the sponsoring registrar's control over that entry — is single, static and held by parties who are not the operator. It is the only element the operator does not own. That is why action against flux infrastructure is a registry or registrar action rather than a network one. Placing the name on hold or redelegating it reaches every host in the population simultaneously, because they all resolve the same label; whereas removing addresses one at a time is a treadmill the operator is happy to run all day. And the point generalises: the property that makes a name useful as a rendezvous — that everyone independently reaches the same place through it — is exactly the property that makes it a single point of failure. ## Why the operator accepts that risk Because they price it and cover it. Flux is bought for uptime against node churn and address-level pressure, not for immortality; the delegation risk is handled by never letting one name be the only path. Behind the fluxed name sit the other pre-committed layers — a compiled list, a generated crop, a dead drop — so the loss of the name is a step down the ladder rather than the end of the population. Confusing the two is the classic error: flux protects the *addresses*, the fallback ladder protects the *rendezvous*. Worth noting who is in the path here, too. When the infected machines are roaming consumer hardware — home broadband today, a hotel tomorrow, a phone hotspot the day after — there is no enterprise resolver and no corporate egress point anywhere in the chain. The naming system is the only shared choke point that exists for that population at all, which is precisely why it carries so much weight. ## Reading a fluxed answer Signs that separate flux from ordinary distributed hosting: a time-to-live far shorter than any performance need, successive answers with **no addresses in common**, addresses scattered across many unrelated consumer networks in many countries rather than a handful of provider ranges, and — under double flux — nameserver names that resolve into the same consumer address space. Legitimate large-scale distribution rotates within a provider's own ranges and does not put its authoritative servers on residential connections. ## What a good answer sounds like Describe the rotation, then immediately climb to the layer that cannot rotate, and finish with the operator's counter to it. Anyone can say "the IPs change a lot"; what shows depth is naming the delegation as the invariant and then explaining why a serious crew still does not lose its population when that invariant is used against them.