ThousandEyes, a network monitoring company, publishes analyses of internet outages, BGP leaks and hijacks, DDoS attacks, RPKI and TCP performance.
HN links it for technical write-ups on incidents like the Route 53 BGP hijack and CenturyLink outage, which commenters call thorough and well visualized.
IMO it's easy to have an opinion on either side of the fence - based on what you've done (or not done). Cloudflare, for example, committed to RPKI very publicly in 2018 [0]. This article, by ThousandEyes, does a nice job of visualizing the problem [1], published in July of 2019. As I read the parent article to this thread it strikes me as a bit defensive - which smells of a lie of omission (not exactly the whole truth, but conveniently cherry picked). They do very little in the article to state two missing arguments: 1) their timeline to implement RPKI (they only state: "At this stage we are looking in to this. We want to be sure we take the right approach, some of which will involved asking our transit providers what they are doing about it.") and 2) the rationale for not being further along of protecting customers with regard to the topic of RPKI.
They also grab Coronovirus as a rationale for doing nothing right now:
"Since this has now happened a few times, we felt it worth giving some more information that may be useful to customers and others who've seen these tweets (either directed at us, or at other ISPs), explaining a bit about what BGP is and how RPKI can extend it, and also our feelings about Cloudflare attempting to build support in this manner, especially now, during the Corona Virus situation."
If you look at this NANOG thread [2] nobody is complaining about ATT announcing they have implemented RPKI. So is there a negative downside? No. Has CloudFlare…
Here's a blog entry [1] about an attack in 2016, with some references to other attacks.
The thing is, you have to maintain an attack for a long time to effectively disrupt service.
The root zone is published -- I imagine large recursive caches may use a local copy, rather than actually querying the root servers; but if they do query the root, the TTLs are 2 days; there's a pretty good chance your recursive resolver will have com. cached. The com. servers also give a 2 day TTL, so for popular domains, there's a good chance those are cached too. DDoS on the nameservers for domains can be effective, though. Even then, it's usually not a total outage.
[1] https://blog.thousandeyes.com/ddos-attack-varying-impacts-dns-root-servers/
While other commenters have given excellent answers, I just want to point out that these numbers probably fall out of the Mathis model of TCP throughput. Here's an article on the topic: https://blog.thousandeyes.com/a-very-simple-model-for-tcp-throughput/
I like my company Thousand Eyes blog a lot on IT, cloud, and the internet. Most of the articles are written by a mix of product management, product marketing, and engineering teams. Check it out whenever you get a chance:
https://blog.thousandeyes.com/
I think you mean the BGP hack.
https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack/
That wasn't reaaaaly an AWS hack. BGP hacks are still an issue since it is mostly an honor system! There are no safeguards against this except fast admin.
Are you thinking of the event in April? That was not a Route 53 outage, that was a BGP hijack.
https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack/