DNS and security news · Sources checked November 7, 2026
Cloudflare One administrators have a new DNS-related signal to review. Before enabling it, check whether existing access policies already act on user risk scores. A new detection may call for investigation and could also affect someone’s access through those policies.
What Cloudflare announced
In its November 6 changelog, Cloudflare added fast-flux detection as a predefined behavior in user and entity behavior analytics, or UEBA. The feature is available on Enterprise plans. Administrators enable it under Risk score > Risk behaviors in the Zero Trust dashboard; detections then contribute to a user’s risk score.
This is a practical review guide based on the announcement and documentation, rather than a report of a hands-on deployment.
Why changing DNS answers can deserve investigation
Fast flux rapidly rotates the IP addresses associated with a domain. Attackers can use that movement to keep malicious infrastructure reachable while making individual servers harder to track and block. Cloudflare’s DNS explainer describes the technique and its use in malicious infrastructure.
Address changes alone do not establish that a device or account is compromised. The joint fast-flux advisory published by national cybersecurity agencies explicitly warns that legitimate services, including content delivery networks and load balancers, can show similar behavior. A useful investigation combines the DNS observation with context about the destination and the activity that caused it.
Check the consequences before turning it on
Cloudflare’s risk-score documentation says predefined behaviors start disabled and, once enabled, are evaluated across the organization’s users. It also documents Access policies that use risk scores. The new announcement does not say that enabling fast-flux detection automatically creates a blocking policy.
Start with a short inventory of applications that already use risk scores in access decisions. Record the policy owner, the risk levels each rule matches and the expected result. Ask the service desk who can investigate a disputed detection and restore access through the approved process. Do not assume this toggle can be limited to one pilot user; confirm any narrower scope with the vendor before planning around it.
For example, imagine an application with an existing policy that excludes high-risk users. If a new detection leaves a user in that category, the policy may affect their access. That is a reason to review the policy, not a claim that every fast-flux detection is assigned High. The announcement does not specify the feature’s default severity.
Give the analyst a concrete next step
Use a small investigation record rather than treating the alert label as a conclusion. The following is an operational checklist, not a description of fields guaranteed to appear in every Cloudflare event:
- Preserve the event context. Record the time, affected user or device, destination and available supporting logs. Keep the evidence in approved internal systems.
- Find the initiating activity. Was this a user opening a page, an application making a background request or something not yet explained? Correlate endpoint and network evidence where available.
- Check the destination’s purpose. Compare it with expected services and current threat intelligence. Avoid visiting a suspected malicious site from an ordinary workstation just to see what happens.
- Separate observation from conclusion. Document what is known, what remains uncertain and what additional evidence would justify containment. A DNS pattern does not identify the person’s intent.
- Record the access impact. If a policy denied access, capture the matching rule and its owner. Resolve confirmed false positives through a scoped review instead of weakening a broad policy to make the alert disappear.
Leave undocumented details open
The announcement does not publish detection thresholds, evaluation latency or accuracy measurements. The general risk-score page checked for this article does not yet list a fast-flux-specific row. Confirm the required traffic visibility and expected event details for your deployment rather than borrowing settings from another risk behavior.
Cloudflare’s general documentation also says disabling a behavior stops future monitoring but leaves earlier detections associated with the user. A rollback plan should therefore cover both the setting and the investigation of existing findings. Assign an owner, define how false positives will be reviewed and check the access-policy consequences before enabling the signal.