[dns-operations] Looking for a public blackhole/sinkhole IP address

Warren Kumari warren at kumari.net
Thu Nov 27 15:38:35 UTC 2014

On Wed, Nov 26, 2014 at 7:12 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> Warren Kumari wrote:
>> This thingie has many aspects that look a bunch like AS112 -- I'm
>> wondering if it makes sense to also request an AS number for this.
>> It's not strictly needed, but having fewer inconsistent origin routes
>> is always nice.
>> It also seems that (also like AS112), networks could do this in one of
>> (at least) 3 ways:
>> 1: They can spin up this route purely within their own network  --
>> basically have one or more places where the route points at null0 /
>> discard and *not announce it to peers / customers* or
>> 2: announce to customers only or
>> 3: be good citizens and announce it to everyone.
>> 1 and 2 already exist, for RTBH (like you mention in the doc), they
>> are just not anycasted. I wonder if we ask the IANA nicely if they'd
>> assign 666.666.666.0/24 to.. oh, bugger....
>> The more people who do this, the more benefit there is - unfortunately
>> this argument often doesn't work on the Internets, but still worth
>> trying...
> If one is trying to dispose of "250 million DNS requests per second" [0]
> or "> 1Mr/s (mega-requests per second)" [1], then you probably *don't*
> want the traffic to be routed to whoever happens to have announced it,
> or anywhere, really.

Yes -- which is why many (most?) networks already have a RTBH
destination / null route. If you are at the receiving end of [0] or
[1], you sure don't want to be routing this back out to a community
blackhole, you want to drop it as soon as possible instead[*]. This
means shuffling it off to something that can drop it ASAP, like as
soon as you touch it -- you'll probably send this to a discard route
(forwarding > filtering) -- in which case you A: route it to your
already existing discard prefix, in which case why not use the address
we are requesting for this? or B: you realize you really should have a
discard prefix -- in which case, why not spin up the prefix we are

>  That seems to be a much different use case (drop
> the traffic as quickly and universally as possible, minimizing
> collateral damage) from routing the traffic to something like a
> community sinkhole.

Yes -- and the whole point of this plan would provide the "as quickly
and universally as possible". The theory (hope) is that *most* people
will spin up this prefix and null route it, preferably on their edges.
Perhaps "community sinkhole^Wblackhole" is the wrong term / conjures
up the wrong image, and "universal blackhole" would be better.
What we are aiming for / proposing is a "toss this as soon as
possible", not "route to a small number of sinkholes run by some
volunteers". The incentive model here is that, the more people who do
this, the more useful it is -- and so, one day when *I* need it, it
will be available. This might suffer from a tragedy of the commons
type problem - I'll just hope that other folk do it, so I don't need
to sink the badness. One nice property that this has versus something
like BGP38 / SAVE is that it is very easy to tell if your peers are
not doing it -- and so you could easily include it in peering /
provider contracts.
What would be really nice (IMO) is, if we get consensus on this, to
recommend that router's do this automagically (with a turn off knob) -
there are already a number of "special" prefixes that some devices
handle (127/8,, 240/4, etc) - having a default <this
prefix>/24 -> discard in devices would make it so that the very first
devices seeing the traffic would dump it.

[*]: Actually, it's unclear if this would have worked for [0] and [1]
- you might need some more granularity than "Aaargh, make this stop!"

> [0] http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/
> [1] https://la51.icann.org/en/schedule/mon-tech/presentation-dafa888-dos-attack-13oct14-en.pdf
> --
> Robert Edmonds
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.

More information about the dns-operations mailing list