Why did the sites that went down in the Dyn DDoS attack (Oct 2016) not have secondary DNS?

Question

Or if they did, why didn't it help them?

(Edit: by "secondary" I mean "not at Dyn")

Answer 1

They probably did.

Checking on one that was actually affected we see that basecamp had 4 DNS servers but all were hosted at dynect.net. So if dynect's infrastructure was attacked it's easily possible none of them were responding well.

dig -t NS basecamp.com

; <<>> DiG 9.8.1-P1 <<>> -t NS basecamp.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39198
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;basecamp.com.          IN  NS

;; ANSWER SECTION:
basecamp.com.       28725   IN  NS  ns3.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns4.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns1.p25.dynect.net.
basecamp.com.       28725   IN  NS  ns2.p25.dynect.net.

Same thing for GitHub

dig -t NS github.com

; <<>> DiG 9.8.1-P1 <<>> -t NS github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22950
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     24417   IN  NS  ns1.p16.dynect.net.
github.com.     24417   IN  NS  ns2.p16.dynect.net.
github.com.     24417   IN  NS  ns3.p16.dynect.net.
github.com.     24417   IN  NS  ns4.p16.dynect.net.

;; Query time: 1 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:09:42 2016
;; MSG SIZE  rcvd: 114

It should be noted that this is an example of putting all of ones eggs in a single basket. Most colocation providers, ISP's, and even many cloud providers talk about redundancy across their multiple datacenter but frequently they are all within a single infrastructure of some type such as all being routed, or black holed, together because all of those IP's share a single BGP ASN from an Internet backbone perspective and although that's designed to prevent looping when mistakes occur it could take all of one of these colocation providers, ISP's, or cloud providers network out temporarily.

This brings up the question, so why weren't the DNS servers on completely different ISP's networks to prevent single points of failures like this. To that I would say it's more an oversight made by the person who selected the datacenter/cloud provider. Sometimes this is due to ease of billing or due to other dynamics of the vendor relationship or system deployment methods but the more formal term for why this happens is simply path dependence (i.e. they do this because that was the way it was done at a previous company and it worked fine there...)

To their credit it does appear the Dyn DNS offers some Enterprise solutions that have a lot of add on features which are probably only available if Dyn DNS is managing all the DNS servers. Interesting risk trade off. I'd love to know what their marketing literature & contractual SLA's says about the redundancy and availability of their infrastructure.

In any case, it would be wise to have DNS servers hosted with more than one provider.