Null Routing in a DDoS Attack: What Blackholing Does to Your IP
A null route, also called a blackhole route, sends all traffic for one IP address to nowhere, upstream of your server, so a DDoS attack stops reaching the network. It also stops every legitimate visitor to that address. Null routing protects shared links and other customers, at the cost of taking the targeted IP offline.
If one of your addresses went dark during an attack, this post explains what happened, how to confirm it from outside, how to design so one dark address is not an outage, and exactly when voxa.host null routes an address.
What is a null route?
A null route is a routing table entry that sends packets for a destination to a discard interface instead of a real next hop. The router accepts the packet and throws it away. Nothing is forwarded, and usually nothing is sent back, so to the sender the address simply stops answering.
In DDoS handling the destination is almost always one host: a /32 for an IPv4 address or a /128 for IPv6. Routers prefer the most specific prefix, so that address is dropped while the rest of its subnet keeps working. The provider gives up one address to protect everything around it.
On a Linux router the idea fits in one line, shown here with a documentation address:
ip route add blackhole 203.0.113.10/32
Hardware routers use a static route to a discard interface, often called Null0, hence the name.
How does blackhole routing work during a DDoS attack?
A null route on the hosting provider's own router helps only a little. By then the packets have already crossed the links into the provider's network, and those links are what a large attack fills. The drop has to happen further out.
Remote triggered black hole filtering, or RTBH, does that. Inside one network, a trigger router announces the targeted /32 over BGP with a next hop that every edge router sends to a discard interface. One announcement, and every edge drops the traffic as it arrives.
The same idea extends to upstream networks. RFC 7999 defines a well known BGP community for it, BLACKHOLE, written 65535:666. A network announces the very specific prefix to its upstream tagged with that community, and an upstream that honours it discards traffic for that address at its own edge, before it reaches the link into the hosting network.
Two details matter on the receiving end. Blackholing is destination based: every packet to the address is dropped, whatever its source, so real visitors vanish with the attack. And it is all or nothing: every port and protocol goes, not only the one under attack.
Why do hosting providers null route an IP?
Because the links and filtering in front of a server are shared. An attack on one address competes with every other customer's traffic, and once it is larger than what can be filtered, everyone on those links pays.
A made up example, not a description of any real network: upstream links totalling 400 Gbps carry 200 Gbps on a normal evening. A 300 Gbps flood arrives for one address. Demand is now 500 Gbps on 400 Gbps of capacity, so one packet in five is lost, for every customer. Blackholing that single /32 upstream returns the links to normal.
For the target, a null route means the attacker got what they wanted: that address is unreachable. That is why it should be the last step after filtering, and why you should know in advance exactly when your provider takes it.
When does voxa.host null route an IP address?
Every KVM VPS and every dedicated server includes 100 Gbps of always on DDoS protection at Layer 3 and Layer 4, filtered upstream, active from delivery, at no extra charge. Attacks within that size are filtered, not null routed.
Above 100 Gbps the rules are:
- The first 5 attacks a month that exceed 100 Gbps are still mitigated at no charge.
- From the 6th such attack in the same month, the targeted IP address is null routed until the attack ends or the server is upgraded to a larger tier.
- Only the targeted address is null routed. Other IP addresses on the same server keep working.
A larger tier raises the cap. Prices below are monthly, per server, exclude VAT, and cover every IP address on that server.
| Tier | Layers | Per month |
|---|---|---|
| 100 Gbps | L3/L4 | Included |
| 500 Gbps | L3/L4 | €156.45 |
| 1 Tbps | L3/L4 | €523.95 |
| 2 Tbps | L3/L4 | €1,048.95 |
| 5 Tbps | L3/L4 | €2,623.95 |
| 10 Tbps + Layer 7 | L3/L4/L7 | €4,723.95 |
Choose a tier as an add on at checkout when you order a VPS or dedicated server, or change it later from the client area. The price is flat, with no fee per attack. Layer 7 filtering exists only on the 10 Tbps tier, so on every other tier HTTP floods are handled in your own stack, as our post on Layer 7 DDoS protection and HTTP floods explains. To size a tier, start with how much DDoS protection you need.
A worked example: a server on the included tier is hit by eight attacks above 100 Gbps in one month. Attacks one to five are mitigated. During the sixth, seventh and eighth, the address each one targets is null routed until that attack ends or the server is upgraded. The other addresses stay up throughout.
How to tell if your IP is null routed or your server is down
Both look like an outage from a browser, but they leave different traces. Test from outside our network, from at least two places, against more than one address.
mtr -rwzc 50 203.0.113.10
mtr -rwzc 50 203.0.113.11
Run mtr against the dark address and against another address on the same server, then compare what you see with this table.
| Check | Null routed address | Server down |
|---|---|---|
| Other IPs on the same server | Answer normally | Silent as well |
mtr to the dark address | Trace stops in the upstream network or at the edge of the hosting network, total loss from there on | Trace reaches the hosting network and stops after the last router before the server |
| Tests from several cities | Total loss everywhere | Total loss everywhere |
| Logging in through another address | Works, the machine is running normally | Fails |
| Traffic seen on the server | Inbound traffic to that address stops completely | Nothing, the machine is not running |
Once logged in through another address, test outbound traffic. Replies to the null routed address are dropped upstream too, so connections sourced from it fail while your other addresses work:
curl --interface 203.0.113.10 -sI https://www.example.com
curl --interface 203.0.113.11 -sI https://www.example.com
Partial loss is a different story. Losing a fifth of your packets, or losing them from some cities and not others, points to congestion or a routing problem on one path. A null route is total and looks the same from everywhere.
How to keep a null route from taking your business offline
A null route removes one address. Whether that is an outage depends on how much of your business sits behind it. Most of the work is cheap and best done before the first attack.
Separate the public service from management and mail
Serve the website or API from one address, administer the server through another, and send mail through a relay rather than from the public address. The public address is the one attackers find. If SSH and your monitoring use an address never published in DNS, you can still log in, read logs and make changes while the public one is dark, and mail that leaves through the relay keeps flowing.
Keep spare IPv4 addresses
One usable IPv4 address comes with every server, and more are a checkout option on VPS and dedicated servers. An unpublished spare lets you move the public service and update DNS while the old address is null routed. Know the limit: if the attacker aims at your hostname, the attack follows the DNS change. Against an attack aimed at a fixed address, moving works.
Lower DNS TTLs before you need them
Resolvers keep a record for as long as its TTL allows. With a TTL of 86,400 seconds, some visitors use the old address for up to a day after a change. With 300 seconds, most move within five minutes. Lower it now, because resolvers keep a cached record until its old TTL runs out.
Run a second server in another location
A standby in a different city, with your code deployed and data replicated, turns a null route into a DNS change. Our guide to pairing two VPS locations for failover covers the setup. For traffic heavy services, a few edge nodes of your own in front of the origin mean a null route on one edge address takes out one node, not the service.
Never leak the origin address
If the address holding your application and data is never public, attackers can only aim at what sits in front of it. Origins leak in predictable ways:
- Mail headers. An application that sends mail directly from the origin writes the origin address into the
Receivedheaders of every message. Relay outbound mail through a separate host. - Old DNS records. Services that archive DNS history remember the A record your domain had before the origin moved behind anything. Give the origin a fresh address after such a move.
- Direct links and forgotten subdomains. Names like
directorstagingstill pointing at the origin, assets linked by IP, and a default virtual host whose certificate names your domain. - Your own responses. Error pages, API responses and debug headers that print the server's address.
Monitor from another city
A checker running on the attacked server cannot report that it is unreachable. Check each public address separately from a machine in another city, so a failed check shows which address went dark and whether the others still answer, the pattern in the table above. Our post on monitoring your own server from another city walks through a setup.
What to send support when an IP is null routed
A precise report saves a round of questions. Send it through our contact page with:
- The affected IP address, and the server or service it belongs to.
- When it went dark, in UTC, as precisely as your monitoring allows.
- Symptoms: total or partial loss, from where, and whether other addresses on the server still answer.
mtroutput from outside our network, to the affected address and to a working one.- Anything you changed recently, such as DNS records, firewall rules or a new service going public.
- Whether you want to wait for the attack to end or move the server to a larger tier.
Keep the server running. A null route lives in the network, not on the machine, so a reboot or reinstall will not bring the address back.
Where to read the full DDoS policy
The tiers, the included 100 Gbps cap and the null route rule are all on our DDoS protection page. If your service has been targeted before, look at the dedicated server range and choose a tier at checkout, so the cap matches your risk from the first day.
Deploy what you just read about
Deploy your first server now.
No minimum term. Intel Xeon builds carry a delivery estimate of under an hour; AMD EPYC builds are made to order. Every configuration has full root, ECC memory and a guaranteed 1 Gbps unmetered port.
Dedicated billed monthly · No setup fee · Full root on every server
- IPv4 address
- One included
- Unmetered port
- 1 Gbps guaranteed
- DDoS protection
- 100 Gbps · L3/L4
- Root access
- Included
- Setup fee
- €0.00
- Minimum term
- None