Blackhole routing is a network defense that deliberately sends selected traffic to a dead end, called a black hole or null route, where the packets are discarded. During a DDoS attack, you can use it to stop a flood from overwhelming the rest of your network.
The catch is simple but painful: if you blackhole a destination, legitimate users usually lose access to it too. You save the building by locking one room and cutting its power. Example
Key Takeaways
- Blackhole routing drops traffic instead of inspecting or forwarding it.
- A local null route drops packets on your equipment, while a BGP blackhole can ask upstream networks to drop them earlier. Example
- Destination-based blackholing sacrifices the attacked IP to protect surrounding infrastructure. Example
- Source-based blackholing targets selected senders, but spoofing and distributed botnets limit its usefulness. Example
- Traffic scrubbing is less destructive because it filters malicious packets and forwards legitimate traffic.
- In Anycast and multi-CDN environments, blackholing should be narrow, scoped, and coordinated with traffic steering. Example
What Is Blackhole Routing?
Blackhole routing means creating a route that leads nowhere useful. When a router matches traffic to that route, it sends the packets to a discard interface, often called Null0, or applies an equivalent discard action. Nothing waits on the other side. The traffic is simply dropped.
You can think of a router as a traffic officer reading destination signs. Under normal conditions, it forwards each packet toward the next network hop. A blackhole route changes the instruction to: “Do not forward this packet anywhere.”
That is why you will also hear the term null route. In everyday network operations, “blackhole route,” “discard route,” and “null route” often describe the same outcome, although the implementation varies by router and network.
Example
The simplest version is local. You add a static route for an IP address or subnet and point it to the router’s discard interface. Traffic reaches that router, matches the null route, and disappears.
The more scalable version is remotely triggered blackhole routing, usually shortened to RTBH. Here, Border Gateway Protocol, or BGP, distributes a routing signal across multiple routers. This lets you trigger the response from a central system instead of logging into every edge router during an attack.
RFC 7999 defines a well-known BLACKHOLE BGP community for destination-based BGP blackhole signaling, commonly represented as 65535:666. An authorized network can attach it to a prefix to request that a neighboring network discard traffic destined for that prefix. It remains an advisory signal. Your ISP, peer, or transit provider must support it, agree to honor it, and validate that you are authorized to advertise the address range.
{{cool-component}}
How Blackhole Routing Works to Drop DDoS Traffic
Imagine your application runs on 203.0.113.25. A volumetric DDoS attack starts sending more traffic than your connection can carry. Your server may not be the first thing to fail. The flood can saturate your internet circuit or create congestion that affects unrelated services sharing the same network.
Blackhole routing gives you an emergency isolation procedure.
1. You Detect the Attack
Monitoring systems notice an abnormal rise in packets, bandwidth, connection attempts, or traffic to one IP. Detection may come from flow telemetry, router counters, a DDoS platform, or your provider. Modern RTBH systems can connect this monitoring directly to automated routing actions.
Volume alone is not enough. A product launch or viral campaign can also produce a spike, which is why automated blackholing needs conservative thresholds.
2. You Identify the Target
You determine which destination is under attack. The narrower the target, the less collateral damage you cause.
RFC 7999 recommends using the most specific practical blackhole prefix, typically /32 for one IPv4 address or /128 for one IPv6 address. Blackholing a full subnet when one IP is attacked can unnecessarily take other systems offline.
3. A Trigger Announces the Blackhole
In an RTBH design, a trigger router or controller injects a route for the attacked address. It attaches a provider-specific community or the well-known BLACKHOLE community. Routing policy changes the route’s next hop to a preconfigured discard destination.
You make one controlled routing change, and the network distributes the instruction to participating routers.
4. Edge or Upstream Routers Drop the Packets
Matching traffic is sent to the null interface. If your provider honors the announcement, it can drop the packets before they cross your access circuit.
The location matters. A null route on your firewall cannot rescue a 10 Gbps connection from a 100 Gbps attack because the link is already full before the firewall sees the packets. Upstream blackholing prevents more of the flood from consuming your downstream capacity.
5. You Withdraw the Route
When the attack ends or another mitigation layer is ready, you withdraw the blackhole announcement and normal routing resumes.
This workflow needs authorization controls, expiration timers, logging, monitoring, and a tested rollback process. RFC 7999 also warns that leaked, more-specific blackhole routes can affect networks outside the intended routing domain.
Destination-Based vs. Source-Based Blackholing: The Difference
There are two main RTBH approaches. The names tell you which packet field drives the drop decision.
Destination-Based Blackholing
Destination-based RTBH drops traffic going to a selected IP address or prefix. This is the common emergency response to a large DDoS attack.
If your attacked IP is 203.0.113.25, you announce that destination as blackholed. Routers discard every packet headed there. Attack traffic stops consuming downstream resources, but real customers also cannot reach the service.
I see destination blackholing as controlled amputation. It does not cure the attacked service. It isolates that service so the rest of your infrastructure can survive.
Source-Based Blackholing
Source-based RTBH drops traffic coming from selected source addresses. RFC 5635 extends RTBH to source-address filtering, commonly using unicast Reverse Path Forwarding, or uRPF. The router checks a packet’s source against routing information and drops it when that source resolves through the configured discard path.
This can keep the destination reachable, but only when the abusive sources are known and stable. DDoS traffic may come from thousands of devices, attackers can spoof source addresses, and shared proxies, VPN gateways, or carrier-grade NAT may place many legitimate users behind one visible address. A source list can become outdated almost immediately.
{{cool-component}}
The Limitations and Trade-Offs of Blackhole Routing as a DDoS Defense
Blackhole routing is fast, simple, and widely available. It can also produce exactly the outage the attacker wanted. That contradiction is the whole story.
It Drops Good Traffic Too
A destination blackhole does not know whether a packet came from a botnet or a paying customer. Both match the same destination and both disappear. Blackholing can still make sense when sacrificing one site protects a much larger network.
It Protects Capacity Only Where the Drop Happens
Dropping packets after they cross a congested link is too late. For volumetric attacks, you want filtering at your provider’s edge, an internet exchange, or another network with enough capacity. That is why an upstream BGP blackhole is usually more useful than a local null route.
It Has Limited Selectivity
Traditional blackhole routing usually works with IP prefixes, not application behavior. It cannot distinguish a malicious HTTP request from a legitimate one when both use the same destination.
Rate limiting, BGP FlowSpec, firewalls, WAF rules, and traffic scrubbing can match more detail, including ports, protocols, packet characteristics, or request behavior. Blackholing is the blunt fallback when precision is unavailable or the attack is too large to process normally.
BGP Mistakes Can Spread
A bad announcement can affect far more users than intended. Operators therefore use prefix authorization, community filtering, route validation, and controls such as NO_EXPORT or NO_ADVERTISE. RFC 7999 recommends checking that the announcing network controls the prefix and limiting unintended propagation.
Automation Needs Guardrails
Monitoring platforms can trigger blackhole routing when traffic crosses defined thresholds, reducing response time during fast attacks.
A safe automated policy should restrict which prefixes can be blackholed, set automatic expiration, alert the network team, and provide a manual override. Otherwise, a false positive can turn an unusual but legitimate traffic spike into a production outage.
Blackhole Routing in a Multi-CDN and Anycast Architecture
Blackhole routing becomes more complicated when your application sits behind multiple CDNs or uses an Anycast network. You are no longer dealing with one server, one route, and one entry point. The same service may be reachable through several providers and dozens of edge locations.
That extra complexity can help you survive a DDoS attack, but only when your routing policies are carefully scoped.
With Anycast, multiple data centers advertise the same IP prefix through BGP. Internet routers normally send each user toward the nearest or most attractive network location. During a DDoS attack, this spreads the malicious traffic across the Anycast network instead of forcing one data center to absorb the entire flood.
In practice, a large Anycast network gives you three advantages:
- The attack is distributed across multiple locations.
- Traffic can be absorbed closer to where it originates.
- Healthy locations can continue serving users when one region has problems.
Blackhole routing should normally be a last-resort layer in this setup. If you blackhole the shared Anycast prefix everywhere, every edge location may stop accepting traffic for that address. You have protected the provider’s infrastructure, but you may also have taken the application offline globally.
That is a much larger action than disabling one overloaded location.
A better approach is to keep the response as narrow as your architecture allows. Your provider might withdraw the route from one point of presence, change its BGP preference, or stop advertising the affected prefix in a specific region. Traffic can then move toward other Anycast locations without making the destination unreachable everywhere.
The available controls depend on the CDN. As a customer, you may not directly manage the provider’s internal BGP advertisements. You usually rely on its DDoS platform, support team, or automated mitigation policies to make those routing changes.
How Multi-CDN Routing Changes the Response
In a multi-CDN architecture, your domain can be served by two or more CDN providers. A traffic management system chooses which provider receives each request based on availability, geography, performance, cost, or current network conditions.
If one CDN is experiencing an attack or capacity issue, you may be able to reduce its traffic allocation and shift users toward another provider.
This only works when the alternate provider can actually serve the application. Your DNS, TLS certificates, cache rules, security policies, origin access controls, and application configuration must already support failover. You do not want to discover during an attack that your backup CDN cannot reach the origin or does not have the correct certificate.
You also need to think about the origin itself. Switching users from one CDN to another does not help if attackers can bypass both providers and send traffic directly to your origin IP. The origin should accept traffic only from approved CDN or scrubbing networks where possible.
Using BGP Blackholing Without Disabling Every Provider
If you own and advertise your own IP space, you may announce the same prefix through multiple network providers. A BGP blackhole request sent to one provider does not necessarily have to affect the others.
Providers often use different BGP communities and different blackhole policies. This means you may be able to ask one upstream provider to discard traffic while another continues advertising and serving the prefix.
However, you should never assume that behavior without testing it.
A blackhole community could be accepted only inside one provider, shared with connected peers, or rejected completely. Poorly filtered announcements can also travel farther than you intended. Your runbook should document:
- Which blackhole community each provider accepts
- Whether it supports IPv4 /32 and IPv6 /128 routes
- Where the traffic will be dropped
- Whether the announcement stays inside the provider’s network
- How quickly the route can be withdrawn
I would also test the process using a non-production address. A DDoS incident is not the right time to learn that one provider interprets your routing community differently than expected.
Where Traffic Scrubbing Fits
In a resilient multi-CDN or Anycast setup, traffic scrubbing should normally come before blackholing. Scrubbing systems analyze the flood, remove malicious packets, and deliver legitimate traffic to your CDN or origin.
Blackholing becomes the emergency brake when filtering is unavailable, the attack exceeds available capacity, or one destination threatens the stability of a much larger network.
The practical order usually looks like this:
- Anycast distributes the incoming traffic.
- DDoS detection identifies the attack pattern.
- Traffic scrubbing removes malicious traffic.
- Multi-CDN steering moves users away from unhealthy providers.
- A narrowly scoped null route isolates any destination that still threatens the network.
Your goal is not to avoid blackhole routing completely. It is to avoid using a network-wide blackhole when a smaller routing change would solve the problem.
The best design sacrifices the smallest possible service, in the smallest possible region, for the shortest possible period. That requires tested failover, provider-specific BGP policies, protected origin addresses, automatic route expiration, and clear rules for when your team is allowed to trigger a null route.
FAQs
How Does Blackhole Routing Differ From Traffic Scrubbing?
Blackhole routing drops every packet that matches the selected route, including legitimate traffic. Traffic scrubbing inspects the incoming flood, removes malicious requests, and forwards clean traffic to your origin. You use blackholing when protecting network capacity matters most. You use scrubbing when the service needs to remain available.
Does Blackhole Routing Stop an Attack or Redirect Damage?
Blackhole routing usually does not stop the attacker from transmitting traffic. It changes where the packets are discarded. If your provider drops them upstream, they cannot saturate your connection or reach the target. The attacked IP may still become unavailable, but the rest of your network avoids the same damage.
Can Blackhole Routing Be Triggered Automatically During a DDoS?
Yes. Your monitoring platform can detect abnormal traffic and announce a BGP blackhole route automatically. This reduces reaction time during a fast attack. I would still require approved prefixes, conservative thresholds, automatic route expiration, alerts, and a manual override, because a false positive can take a healthy service offline.
