APNIC Labs

An excellent find!

> We will be destroying all “raw” DNS data as soon as we have performed statistical analysis on the data flow. We will not be compiling any form of profiles of activity that could be used to identify individuals, and we will ensure that any retained processed data is sufficiently generic that it will not be susceptible to efforts to reconstruct individual profiles. Furthermore, the access to the primary data feed will be strictly limited to the researchers in APNIC Labs, and we will naturally abide by APNIC’s non-disclosure policies.

So it's a 5 year research program, with options to extend it as a research program. To me, that means they intend to keep DNS data for up to 5 years (or longer) before performing statistical analysis and processing on it. Here is APNIC Labs's privacy policy http://labs.apnic.net/privacy.shtml and APNIC's privacy policy https://www.apnic.net/about-apnic/corporate-documents/documents/corporate/privacy/#2.4

So much for "privacy-first".

I am no expert.

But a route leak forces traffic to take a different path, and this potentially results in a pipe being inundated with a significant volume of traffic that cannot be handled by ISPs along that route (or simply a dead-end).

i.e. imagine an ISP in Rio suddenly declaring that they are the best route to reach the networks that contain facebook.com and google.com ... that ISP will DDoS itself or one of their downstream partners. An ISP may not even notice this, but their peers and partners probably will.

A couple of years ago a BGP route leak took out the entire internet for a few hours for people in Australia. They're fairly common unfortunately, but tend to have limited impact and are resolved quite quickly.

More info: https://labs.apnic.net/?p=139

A few years old but here you go:

https://www.retevia.net/fast/

In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:

https://labs.apnic.net/?p=520

Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).