Why was October 2016 Dyn attack limited to East Coast?
If we specifically talk about the case of twitter.com; As why site was not accessible from East coast and why it was accessible from rest of the world (roughly).
BGP routes announcement of same IP network from multiple locations and existence of infrastructure at various location is the answer of your query.
On doing the dig for twitter.com from multiple open-resolvers, i got multiple IP address for the said domain but they all belongs to same /24 IP network.
Kansals-MacBook:~ Kansal$ dig twitter.com A +short @4.2.2.4
104.244.42.193
104.244.42.65
Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.8.8.8
104.244.42.129
104.244.42.65
Kansals-MacBook:~ Kansal$ dig twitter.com A +short
104.244.42.65
104.244.42.193
Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.20.247.20
104.244.42.129
104.244.42.1
Kansals-MacBook:~ Kansal$
So, twitter site is hosted on 104.244.42.0/24 segment (getting an ip from this segment only from various locations; corner cases may exist).
On doing the WHOIS for this IP segment, i got to know that the following results -
Kansals-MacBook:~ Kansal$ whois 104.244.42.65
NetRange: 104.244.40.0 - 104.244.47.255
CIDR: 104.244.40.0/21
NetName: TWITTER-NETWORK
NetHandle: NET-104-244-40-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS13414
Organization: Twitter Inc. (TWITT)
RegDate: 2014-12-08
Updated: 2014-12-08
This means that 104.244.40.0/21 IP segment belongs to twitter.
Twitter has announce this segment (/21 or /22 or /24) from its various Data Centres (or from co-locations facilities) across the world.
So, when i request for twitter.com, i go to Singapore (as i am getting best routes from Singapore for this particular segment) And when someone tries to access twitter.com from East coast, he may have the best path for the segment from the location which was under DDoS attack.
Because of this announcement possibility of the IP segment from multiple locations and existence of infrastructure across the globe, service was only affected for few (locations which was under attack).
Hope this answers your query.
Maps on the Internet showed that the focus of the Dyn DDoS attack was on the East Coast of the US. But why?
This is because the first wave of attack happened mainly on the east coast Chicago, Washington D.C. and New York where three DNS data centres of Dyn are.
My DNS is 8.8.8.8 (Google Public DNS). Yet when I tried to reach twitter.com, my computer could not resolve the name. Suppose the DNS TTL expired and Google had to issue a recursive query that landed eventually at Dyn, which perhaps is the authoritative DNS for twitter. (Is that true?)
You are absolutely correct this might have happened, Google's DNS cache entries might have expired and it had to do a recursive query to a non-responding Dyn DNS Server, Here is why:
- You are in Colorado, connected to some XYZ ISP. When you try to open twitter.com. Machine tries to get the IP address of it from 8.8.8.8 which is the DNS you are using in your machine.
- Now 8.8.8.8 doesn't belong to XYZ ISP it belongs to Google which may be in Colorado or somewhere else(maybe on the east coast), Even if 8.8.8.8 is or would have been in Colorado your ISP may not be connected to it(directly). So it may still be getting best route(to 8.8.8.8) from somewhere else(maybe east coast). Saturated point: there are N number of Google's Public DNS server located at different locations and you do not know to which one you are querying to(which depends on best route to 8.8.8.8 from your ISP) this is a concept of anycasting where same IP address are situated at multiple location in order to provide higher availability of service.
- Lets suppose you reach 8.8.8.8 with your query and as you said the TTL for twitter.com has expired. Now 8.8.8.8 has to make a recursive query to get the address of twitter.com for you, So it has to go through a process of asking Root Name Server -> gTLD -> Root server of twitter.com(in this case Dyn hosted) the following servers it gets from the query to gTLD.
prok-MacBook:~ anirudh_malhotra$ dig twitter.com @g.gtld-servers.net. ; <<>> DiG 9.8.3-P1 <<>> twitter.com @g.gtld-servers.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11045 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;twitter.com. IN A ;; AUTHORITY SECTION: twitter.com. 172800 IN NS ns1.p34.dynect.net. twitter.com. 172800 IN NS ns2.p34.dynect.net. twitter.com. 172800 IN NS ns3.p34.dynect.net. twitter.com. 172800 IN NS ns4.p34.dynect.net. ;; ADDITIONAL SECTION: ns1.p34.dynect.net. 172800 IN A 208.78.70.34 ns2.p34.dynect.net. 172800 IN A 204.13.250.34 ns3.p34.dynect.net. 172800 IN A 208.78.71.34 ns4.p34.dynect.net. 172800 IN A 204.13.251.34 ;; Query time: 146 msec
Notice there are four name servers for twitter.com, which will tell 8.8.8.8 what is the IP of twitter.com, Now obviously Dyn would want to have multiple locations of the same name server(anycasting, just like google's public DNS) and also would want the name servers at different locations(maybe some at east coast, Some at west or even some out of the US)
- So again when 8.8.8.8 goes out to query one of these name servers it may or may not go to the east coast servers, which entirely depends on: what is the best route to these servers(or rather IPs of these servers)
Conclusion: twitter.com not working in XYZ ISP in Colorado when attack was on east coast would have happened because Either you were querying a 8.8.8.8 server which was located in east coast which was intern querying the east coast affected servers of Dyn(due to its proximity and getting best route from there) Or the 8.8.8.8(which may still be on west coast) would still have been querying the Dyn east coast affected servers because of the best route from there. So even me sitting in India may not get twitter.com(although highly unlikely, due to high amount of redundancies) for precisely the same reason.
Geographically load-balanced DNS See the following answer for more detail:
https://security.stackexchange.com/a/140517/9195
I'll also point out that the system you hit at 8.8.8.8 is probably not the system I would hit at 8.8.8.8 due to BGP scaling tricks. For some DNS queries we will get different results (probably just Google's sites and geographically load-balanced sites) but otherwise they would be the same.
FWIW: I see the following for twitter from multiple locations and it looks like all of their DNS servers are currently hosted at dynect.net Dyn DNS:
dig -t NS twitter.com
; <<>> DiG 9.8.1-P1 <<>> -t NS twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41734
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com. IN NS
;; ANSWER SECTION:
twitter.com. 82622 IN NS ns2.p34.dynect.net.
twitter.com. 82622 IN NS ns3.p34.dynect.net.
twitter.com. 82622 IN NS ns4.p34.dynect.net.
twitter.com. 82622 IN NS ns1.p34.dynect.net.
;; Query time: 8 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:39:33 2016
;; MSG SIZE rcvd: 115