Two Routes to a Dead Server

The short version. A volumetric DDoS is a physics problem before it is a security problem: you cannot drop a packet that has already saturated the pipe it arrived on. Everyone who mitigates DDoS is really answering one question: where do you stand to catch the flood before it reaches the narrow part? Cloudflare answers with a giant anycast network in front of your origin. Nemesis answers in two places at once: the same DNS-fronted edge, and a program running in your own server's kernel that drops hostile packets before they touch the network stack. The two routes cover each other's blind spots. This is an honest tour of both, including the part where a global anycast network is genuinely better than we are.

The pipe is the physics

Strip away the acronyms and a denial-of-service attack is a capacity argument. Every link has a width. When more traffic arrives than the link can carry, packets queue, then drop, and the drops are indiscriminate: the flood and your customers land in the same overflowing bucket. By the time that happens, no filter on the far side of the link can help, because the damage is the saturation itself, not the individual packets.

This gives you exactly two honest ways to win:

Get in front of a wider pipe. Terminate the traffic somewhere with far more capacity than the attacker can muster, filter it there, and forward only the clean remainder over your narrow last mile. This is what an anycast scrubbing network does.
Never let it build to saturation. Detect the attack while it is still small, identify the sources, and get a drop installed upstream of the narrow link before the flood reaches full volume.

Most real defenses are a blend. What distinguishes them is where they stand and how early they move. Nemesis stands in two places.

A server has two front doors

Almost every discussion of DDoS assumes traffic reaches your server one way: a user resolves your domain, and the packets follow DNS to your address. Hide that address behind a proxy and you have hidden the server. That is the DNS route, and it is the whole premise of the orange-cloud model.

But a production server has a second front door that DNS never touches:

The attacker who already knows your origin IP (leaked in an old DNS record, a TLS certificate log, an email header, a misconfigured subdomain) and hits it directly.
The API client, mobile app, webhook sender, or partner integration that connects to an address, not a hostname behind your proxy.
Anything that reaches the box on a port your DNS-layer proxy never fronts.

A defense that lives only at the DNS edge cannot see any of this. It is guarding the front door while the side door stands open. Nemesis puts a guard on both doors, and that is the core of the architecture.

flowchart LR
  A[Attacker / users] -->|DNS route| E[Nemesis edge<br/>anycast-style proxy<br/>origin hidden]
  A -->|origin-direct / API| S
  E -->|clean traffic only| S[Your server]
  subgraph S[Your server]
    X[Nemesis agent<br/>XDP in the kernel] --> K[Network stack]
  end
  style E fill:#173a5e,stroke:#5aa2ff,color:#fff
  style X fill:#1f2d1a,stroke:#42e08c,color:#fff

Route one: the DNS edge

The DNS route is the familiar one, and Nemesis runs it the familiar way. Your domain points at our edge, not at your origin. The origin address is never in public DNS. Traffic terminates at the edge, where we can inspect it, rate-limit it, challenge it, and absorb what capacity allows before forwarding only clean requests to your hidden origin over a connection the attacker cannot target.

Everything good about the orange-cloud model applies here: the origin disappears, and a flood aimed at a hostname hits absorbent infrastructure instead of your last-mile link. This is table stakes, and we are not pretending it is novel. It is the other route that makes it more than table stakes.

Route two: the kernel on your own box

The second guard is a small program the Nemesis agent loads into your server's kernel using XDP (eXpress Data Path). XDP runs at the earliest possible point in the receive path, before the packet is turned into a socket buffer, before the firewall, before anything in userspace wakes up. A drop there costs almost nothing, and it happens on your server, so it works for traffic that never went near DNS: origin-direct floods, API abuse, the side door.

The kernel program does four things, and every one of them is fail-open (any parse error, any doubt, the packet passes):

Known-bad drop. A longest-prefix match against a published blocklist. A source on the list never reaches your stack.
Edge-only ingress. When you turn it on, the agent drops any packet arriving at a fronted port from a source that is not our edge. This is what closes the side door: even if an attacker finds your origin IP, the kernel refuses everything that did not come through the edge.
SYN-flood defense. A per-source new-connection rate limiter in the datapath, backed by the kernel's own SYN cookies, so a spoofed handshake flood costs the box nothing to reject.
A learning envelope. It counts per-application packet rates to learn what normal looks like, so a spike is visible before it is a decision.

We verified all four the un-fun way: compiled the kernel program, loaded it on a real machine, and threw a heavy, bursty flood at it from a load generator. Blocklisted sources: dropped at line rate, one hundred percent, zero reaching the stack. Edge-only: origin-direct traffic dropped, edge traffic untouched. SYN-rate: excess connections limited while the baseline flowed. And in observe mode, the same program counted every one of those would-be drops and let all of it through. That last sentence is the important one.

Earn the right to block: observe, learn, enforce

A DDoS filter that is wrong is worse than no filter, because being wrong means dropping your own customers during the exact moment they are trying to reach you. So neither route is trusted to block by default. Both move through the same three postures, and you set them from one place:

Learn. The system watches and builds a baseline of what your traffic actually looks like. It never drops.
Observe. Baselines are ready. It now counts every packet it would have dropped, so you can see the decision it wants to make, on your real traffic, with the consequences still hypothetical.
Enforce. Only now does it drop.

The same three words mean the same thing on the DNS edge and in the kernel, and they are one control in your dashboard, not two systems with two vocabularies. You watch the "would have dropped" numbers until they are obviously right, and then you turn it on. A defense earns the right to enforce by showing its work first.

flowchart TD
  L[Learn<br/>build baseline · never drop] --> O[Observe<br/>count would-drops · never drop]
  O --> N[Enforce<br/>drop for real]
  N -.emergency kill-switch.-> O
  style L fill:#3a3417,stroke:#f9b14a,color:#fff
  style O fill:#173a5e,stroke:#5aa2ff,color:#fff
  style N fill:#1f2d1a,stroke:#42e08c,color:#fff

Killing the attack while it is still small

Standing in two places is only half the idea. The other half is moving early, because of the physics: the cheapest flood to stop is the one that has not reached volume yet.

Nemesis watches blocked traffic across every protected server at once and promotes the worst actors to a global blocklist that every enrolled agent pulls. Three signals drive it:

Herd. A source hammering several different customers' sites is a botnet node, not a bad day. It goes to the global list, so a server it has not even reached yet is already dropping it.
Ramp. A single source climbing a steep short-window curve gets killed on the way up, before it reaches full rate on any one target.
Carpet. An attack spread thin across a whole subnet, each source too quiet to trip a per-IP limit on its own, is caught by aggregating the subnet.

Because one customer's attack immunizes the rest of the fleet, the network gets harder to hit the more of it there is. None of this runs in your request path; it is computed out of band and shipped to the datapath as a list.

When the flood is bigger than your pipe

Here is the honest limit. If an attacker can push more traffic at your origin than your uplink can physically carry, nothing running on that origin can save it, ours included. You cannot drop what has already filled the pipe. For that case there is only one real answer: get the drop installed above the origin, in the network itself.

Nemesis does this by signaling upstream over BGP — FlowSpec to install a precise source filter where your transit provider supports it, or a remote-triggered blackhole where it does not. When a source crosses the volumetric bar, we stage the announcement and a speaker pushes it to your peer, so the flood is dropped in the carrier's network before it reaches your link. We are equally honest that this rail only enforces if you have a FlowSpec-capable or blackhole-community relationship with your upstream. Without one, we still detect and stage the request and record the incident; we just cannot make someone else's router act.

Where Cloudflare wins, plainly

A comparison is worthless if it only flatters the author. So, directly:

Cloudflare's advantage is real and it is capacity. They operate a global anycast network with scrubbing capacity measured in tens of terabits per second. For a massive, pure volumetric flood, that capacity absorbs the attack at their edge and your origin never feels it. We do not operate a network of that size, and we will not pretend a clever kernel program is a substitute for physics. If "survive an arbitrarily large volumetric flood with zero origin involvement" is your single requirement, a hyperscale anycast network is the right tool, and that is not us today.

Where Nemesis is different, and for many teams better:

The second door. Cloudflare protects what flows through Cloudflare. The moment traffic reaches your origin another way — origin-direct, API, a leaked IP — you are outside its coverage. The Nemesis kernel agent drops that traffic on the box itself. You do not have to route a service through anyone to protect it.
You own the drop. The enforcement point is a program on your server that you can see, put in observe mode, and turn off. It is not a decision made inside a network you cannot inspect.
Herd immunity without a monopoly. You benefit from cross-customer attack intelligence without having to put the majority of the internet behind one company to generate it.
One honest posture. Learn, observe, enforce — the same three states on both routes, with the "would have dropped" evidence in front of you before anything drops.

The sharpest way to say it: **Cloudflare is a bigger pipe in front of your origin. Nemesis is a bigger pipe in front of your origin and a guard inside it.** For volumetric-only, the bigger pipe may be all you need. For everything that reaches a real server through a door DNS never sees, the guard inside is the part nobody else is shipping.

What to take away

DDoS is decided by where you filter relative to the narrow link. Filtering after saturation is filtering nothing.
A server has two front doors. The DNS edge guards one. Only something on the box guards the other.
Enforcement you cannot trust is enforcement you will leave in monitor mode forever. Learn, observe, then enforce — with the evidence shown first — is how a filter earns the right to block.
For pure hyperscale volumetric, anycast capacity wins, and we say so. For the origin-direct, API, and side-door traffic that capacity never sees, the kernel is where the fight is, and that is the ground Nemesis holds.