Why Blackholing Exists
RTBH (Remote Triggered Black Hole) routing was designed for one specific scenario: link saturation. When attack volume exceeds your available bandwidth, the flood consumes your entire transit link. Every service behind that link goes down, not just the target. RTBH tells the upstream to drop traffic destined for the target IP at their edge, before it reaches your link. The rest of your network is preserved.
This is a valid and well-understood technique. When a 10 Gbps flood hits your 1 Gbps transit, RTBH is sometimes the only way to save the other services sharing that link. The technique works exactly as intended for that use case.
Why Blackholing Is Not Enough
The problem is when blackholing becomes the default response to every attack. Most DDoS attacks do not saturate transit links. A 200,000 PPS SYN flood against a server on a 10 Gbps port uses a fraction of the available bandwidth. A DNS amplification burst at 500 Mbps on the same link has plenty of headroom. These attacks can be handled without taking the server offline.
When you blackhole a server that is receiving a sub-link-capacity attack, you achieve the same outcome the attacker wanted: the server is unreachable. Legitimate users cannot connect. The service is down. The only difference is that you made the decision rather than the attacker, and your transit link is preserved. For the users of that service, the result is identical.
Blackholing is a network-protection technique, not a service-protection technique. The distinction matters when your goal is to keep services available during attacks, not just to preserve bandwidth for other services.
Alternative 1: On-Server Filtering
The fastest and most surgical response is filtering on the target server itself. iptables and nftables rules applied directly in the kernel can handle most attack vectors without any external coordination:
- SYN floods: SYN cookies (net.ipv4.tcp_syncookies) handle SYN floods at the kernel level without consuming connection table entries. Combined with rate limiting on new connections per source IP, this handles the most common attack vector.
- Amplification/reflection: Rate limiting by source IP for UDP traffic from known amplification ports (DNS port 53, NTP port 123, memcached port 11211). Drop or rate-limit rather than blackhole.
- Reflection attacks: Port-specific drops for traffic from source ports commonly used in reflection (chargen, SSDP, CLDAP). These source ports should never appear in legitimate traffic to most servers.
On-server filtering works for any attack that does not saturate the inbound link. The rules apply in 1-2 seconds. Legitimate traffic continues to flow. The server stays online. No BGP changes, no upstream coordination, no DNS propagation delay.
Alternative 2: BGP FlowSpec
FlowSpec pushes specific filtering rules to upstream routers using BGP. Unlike RTBH, which drops all traffic to a destination, FlowSpec drops only traffic matching specific patterns:
- Drop UDP from source port 53 above a rate threshold (DNS amplification)
- Rate-limit TCP SYN to the target above a configured threshold
- Block traffic from specific source prefixes
- Drop ICMP echo-reply above a rate threshold
Legitimate traffic passes normally. Only the attack traffic is filtered. FlowSpec operates at the upstream router level, so it can handle attack volumes that exceed what on-server filtering can absorb. It requires FlowSpec-capable upstream routers (Juniper MX, Nokia SR, Cisco IOS-XR, and others support it).
The trade-off is that FlowSpec rules propagate via BGP, which adds a few seconds of latency compared to on-server rules. For attacks that overwhelm on-server filtering but do not saturate the link, FlowSpec is the appropriate escalation.
Alternative 3: Cloud Scrubbing
Cloud scrubbing diverts traffic through a scrubbing center that separates attack traffic from legitimate traffic. Clean traffic is forwarded to the origin server. Services stay online throughout the process.
Scrubbing is effective for large volumetric attacks that exceed what on-server filtering or FlowSpec can handle. Providers like Cloudflare Magic Transit, Akamai Prolexic, and others operate scrubbing infrastructure at scale. The trade-off is some added latency from the traffic diversion and the time required to activate the diversion (seconds to minutes depending on the implementation).
For always-on scrubbing deployments, traffic flows through the scrubbing infrastructure continuously, so activation delay is eliminated. For on-demand deployments, the detection-to-activation gap determines how quickly the scrubbing begins.
The Escalation Model
The most resilient architecture uses all four techniques in sequence, starting with the least disruptive and escalating only when the current level is insufficient:
- On-server filtering (Level 1): Immediate, surgical. Applied in 1-2 seconds. Handles most attacks. No external coordination needed.
- BGP FlowSpec (Level 2): Upstream, still surgical. Drops specific traffic patterns at the router level. Handles attacks that overwhelm on-server capacity.
- Cloud scrubbing (Level 3): Volumetric protection. Diverts and cleans traffic through external infrastructure. Services remain available.
- RTBH (Level 4): Last resort. Drops all traffic to the target at the upstream edge. Protects the transit link when nothing else can keep up.
Each level preserves more service availability than RTBH. Automatic escalation means the system tries the least disruptive option first and only escalates when monitoring confirms the current level is not containing the attack. Automatic de-escalation means mitigation rules are withdrawn when the attack subsides, preventing stale configurations.
When You Still Need RTBH
There are scenarios where RTBH is the right response. When attack volume truly exceeds your available bandwidth and the upstream link is saturated, on-server filtering cannot help because the packets never reach the server. FlowSpec may not be enough if the attack vector is too diverse to filter surgically. Scrubbing may not activate fast enough or may not be configured for that prefix.
In those cases, RTBH saves the rest of your network. That is its purpose. The point is not that RTBH is wrong. The point is that it should be the last step in an escalation chain, not the first and only response to every attack.
Four mitigation levels before blackholing. Flowtriq starts with on-server rules and escalates only when necessary. $9.99/node/month, 14-day free trial.