The invalid BGP route advertisements redirected folks to the attacker's DNS servers, which served invalid responses to queries.
In this instance, had myetherwallet.com been signed, and had a user been using a DNSSEC validating resolver, they would not have visited the invalid site. The attacker's DNS responses would not have validated.
Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS resolver at 8.8.8.8 would not have visited the invalid site.
Again: the attackers control IP addresses. All of them (or, enough to randomly claim AWS addresses from places in the topology nowhere close to AWS). It doesn't matter what the DNS says.
So with global anycast bgp, people usually use it for short sorts of things, preferably single packet requests, and redirect to non-anycast addresses for longer TCP streams so that there aren't problems from flapping. The idea is that if one dns packet goes to ns1 and then next packet goes to ns2 on the other side of the world, we're cool. I get my answer from both, as those two packets are different queries. But if it's a webserver and packet 1 of my tcp stream goes to lb1, and packet two goes to lb2 on the other side of the world? lb2 is going to send me a rst packet because it has no idea about the tcp connection I'm speaking
In the legitimate world, this usually means you global anycast your DNS servers, which then respond to queries with IP addresses of load balancers that are only announcing from one location, out multiple providers.
I think this maybe could be extrapolated to a BGP attack of this nature and could explain why the attacker, in this case, focused on attacking the DNS server rather than a different piece of the stack.
I'm guessing that your global anycast setup in the legitimate world is going to be way more reliable and flap a lot less than whatever the attacker can cobble together out of upstreams with inadequate prefix filtering.
Note, I'm not trying to claim that the attacker couldn't take over the end machines that serve longer TCP streams; I'm just pointing out that the attacker has good reason to attack DNS first if possible, for the same reasons as the legitimate operators have for using global anycast for DNS and not for HTTP.
(as further trivia, I have seen setups where the http server was global anycast, but that webserver only returned really short responses, 3xx redirects, again redirecting the request to a non-anycast webserver.)
no, in this case, the attackers controlled the IP address of the DNS server, not of 1.2.3.4 (the actual web server)
DNSSEC would have prevented you from resolving this invalid domain their fake DNS servers would have tried to send.
In this instance, had myetherwallet.com been signed, and had a user been using a DNSSEC validating resolver, they would not have visited the invalid site. The attacker's DNS responses would not have validated.
Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS resolver at 8.8.8.8 would not have visited the invalid site.