5

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

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

3

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.

| improve this answer | |
  • 1
    amazon.com (also affected) instead shows currently 4 servers at dynect.com and 2 servers at ultradns.com. Note sure if the last where added during the attack or if they had them before. And spotify (also affected) has currently 4 of their own name servers. Thus I guess explaining the impact of the attack based on a current view of the NS alone is not enough. – Steffen Ullrich Oct 22 '16 at 6:00
  • We'd need more information about what all was attacked to really know. I believe Bruce Schneier's comment about someone testing the infrastructure is very likely part of what was going on here. They probably wanted to see how quickly different companies responded. threatpost.com/… – Trey Blalock Oct 22 '16 at 6:18
  • I agree. Right now there are not enough public technical information about what's really going on. – Steffen Ullrich Oct 22 '16 at 7:03
  • Just to point out (in case such info may be useful ), around 2:30 PM (MDT) github migrated to a different DNS provider: status.github.com/messages I repeated the dig query just now, but it still shows the 4 dyn servers there. – Sergiy Kolodyazhnyy Oct 22 '16 at 10:48
  • 1
    Easier analytics & additional features is what I suspect sold them on it. – Trey Blalock Oct 22 '16 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.