Perché i siti che sono andati giù nell'attacco Dyn DDoS (ottobre 2016) non hanno il DNS secondario?

Probabilmente lo hanno fatto.

Controllando su uno che è stato effettivamente colpito vediamo che il campo base aveva 4 server DNS, ma tutti erano ospitati su dynect.net. Quindi, se l'infrastruttura di dynect è stata attaccata, è facilmente possibile che nessuno di loro stia rispondendo bene.

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.

La stessa cosa per 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

Va notato che questo è un esempio di mettere tutte le uova in un unico paniere. La maggior parte dei fornitori di servizi di colocation, ISP e persino molti provider di servizi cloud parlano di ridondanza attraverso il loro data center multiplo, ma spesso sono tutti all'interno di una singola infrastruttura di qualche tipo, come tutti i router o black blacked, perché tutti questi IP condividono un singolo BGP ASN da una prospettiva backbone Internet e sebbene sia progettato per impedire il looping in caso di errori, potrebbe richiedere l'uscita temporanea di tutti questi provider di colocation, ISP o provider di servizi cloud.

Questo fa sorgere la domanda, quindi perché i server DNS non erano su reti di ISP completamente diverse per evitare singoli punti di errore come questo. Per questo direi che è più una svista fatta dalla persona che ha selezionato il fornitore di datacenter / cloud. A volte ciò è dovuto alla facilità di fatturazione oa causa di altre dinamiche della relazione del fornitore o dei metodi di distribuzione del sistema, ma il termine più formale per cui questo accade è semplicemente path dependence (cioè lo fanno perché era così che è stato fatto in una precedente azienda e ha funzionato bene lì ...)

A loro credito sembra che Dyn DNS offra alcune soluzioni Enterprise che hanno un sacco di funzionalità aggiuntive che sono probabilmente disponibili solo se Dyn DNS gestisce tutti i server DNS. Interessante scambio di rischi. Mi piacerebbe sapere quale sia la loro letteratura di marketing & gli SLA contrattuali parlano della ridondanza e della disponibilità della loro infrastruttura.

In ogni caso, sarebbe saggio avere server DNS ospitati con più di un provider.