Skip to content

SYSTEM Cited by 1 source

dosd (denial-of-service daemon)

dosd (denial-of-service daemon) is Cloudflare's per-server user-space heuristic engine that analyses packet samples from XDP/eBPF and generates the packet-dropping eBPF programs used to mitigate volumetric DDoS attacks. It is the user-space half of a kernel/user-space split: the kernel hot path samples packets via an eBPF program attached to XDP, routes samples to dosd, and dosd compiles its output back down to eBPF rules that drop matching packets at XDP line rate.

Named publicly for the first time (in a wiki-searchable form) in Cloudflare's 2025-06-20 writeup of the 7.3 Tbps DDoS attack autonomously mitigated across 477 data centres.

How it works (per-server loop)

  1. Sample — an XDP/eBPF program samples packets from the Linux kernel's receive path (see systems/ebpf) and delivers them to user space.
  2. Look for patterns — dosd inspects the sample stream for commonalities in packet-header fields (sport / dport / flags / payload length / TTL / fragment offset / specific byte offsets) and for anomalies (values outside the expected distribution for the customer's baseline traffic), plus proprietary heuristics.
  3. Generate fingerprint permutations — for each candidate pattern, dosd enumerates permutations — different subsets of header fields and constraints — producing a small population of candidate fingerprints that each cover the pattern at different specificities.
  4. Count hits (data-streaming algorithm) — each candidate fingerprint is scored by sample-matches using a streaming- algorithm aggregate (heavy-hitters sketch — likely Count-Min / Space-Saving / similar; the post is non-specific). The goal is the most selective fingerprint: surgical enough to match the attack without collateral false-positives.
  5. Threshold gate — if the top fingerprint's hit rate exceeds an activation threshold (false-positive guard), compile it to an eBPF program using a fingerprint-syntax DSL.
  6. Compile and attach — push the eBPF program to XDP so packets matching the fingerprint are dropped in-kernel before user-space work.
  7. Gossip — the top fingerprint permutations are multicast/gossiped within the data centre and globally so peer servers get the mitigation state without independently re-deriving it.
  8. Expire — once the attack ends and hit-rate decays, the rule times out and is removed.

Customer-facing abstraction

dosd is exposed to customers as the DDoS Protection Managed Rulesets — a user-friendly group of managed rules that front the internal fingerprint engine. Customers tune sensitivity and action but do not directly author fingerprints.

Why kernel/user-space split

The split is the canonical two-stage evaluation shape:

  • Kernel (XDP/eBPF) — O(1) per packet, bounded complexity (eBPF verifier limits), no state beyond maps. Answers "does this packet match a compiled fingerprint?".
  • User space (dosd) — full heuristic engine with streaming aggregates, multi-permutation search, threshold decisioning, gossip state. Answers "what fingerprint should we be dropping right now?".

This is the same architectural split as the Datadog FIM Agent (different domain — file-event monitoring vs DDoS mitigation), and first wiki instance of the pattern applied to a DDoS data plane.

Scale (per 2025-06-20)

  • Ran on every server in every Cloudflare POP; 477 data centres across 293 locations participated in the 7.3 Tbps mitigation.
  • Detected, mitigated, and auto-expired the record attack without human intervention, alerts, or incidents.
  • Sample rate, per-server CPU cost, fingerprint-compile latency, and gossip convergence time not disclosed in the writeup.

Caveats

  • Closed source — dosd is Cloudflare-internal; no open-source equivalent is referenced.
  • Heuristic — mitigation efficacy depends on attack traffic having enough structure to fingerprint. A truly random-payload attacker would frustrate the permutation search (the post doesn't address this edge case).
  • Single-writeup disclosure — the system name and design are drawn from one blog post; deeper internals (the exact streaming algorithm, the sample-rate adaptation, the gossip protocol mechanism, the eBPF-compile DSL grammar) are not public.
  • Boundary with systems/pingora / pingora-origin — dosd is the L3/L4 network data plane; Cloudflare's HTTP-layer DDoS defences sit in the pingora stack and are a distinct subsystem.

Seen in

Last updated · 200 distilled / 1,178 read