¿Por qué los sitios que sufrieron el ataque DDoS de Dyn (octubre de 2016) no tenían DNS secundario?

5

O si lo hicieron, ¿por qué no les ayudó?

(Editar: por "secundario" quiero decir "no en Dyn")

    
pregunta joseph_morris 22.10.2016 - 06:51
fuente

1 respuesta

3

Probablemente lo hicieron.

Al verificar uno que realmente se vio afectado, vemos que basecamp tenía 4 servidores DNS pero todos estaban alojados en dynect.net. Entonces, si la infraestructura de Dynect fue atacada, es fácil que ninguno de ellos respondiera bien.

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.

Lo mismo para 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

Debe tenerse en cuenta que este es un ejemplo de poner todos los huevos en una sola canasta. La mayoría de los proveedores de colocación, ISP e incluso muchos proveedores de la nube hablan sobre la redundancia en sus múltiples centros de datos, pero a menudo están todos dentro de una sola infraestructura de algún tipo, como que todos están enrutados, o en negro, juntos porque todos esos IP comparten un único BGP ASN desde una perspectiva de la red troncal de Internet y aunque está diseñado para evitar los bucles cuando se producen errores, podría eliminar temporalmente a uno de estos proveedores de colocación, ISP o proveedores de la nube.

Esto plantea la pregunta, entonces ¿por qué los servidores DNS no estaban en redes ISP completamente diferentes para evitar puntos únicos de fallas como esta? A eso le diría que es más una supervisión realizada por la persona que seleccionó el centro de datos / proveedor en la nube. A veces esto se debe a la facilidad de facturación o a otras dinámicas de la relación de proveedor o los métodos de implementación del sistema, pero el término más formal por el que esto sucede es simplemente dependencia de ruta (es decir, lo hacen porque así se hizo en una empresa anterior y funcionó bien allí ...)

Para su crédito, parece que Dyn DNS ofrece algunas soluciones empresariales que tienen muchas funciones adicionales que probablemente solo estén disponibles si Dyn DNS administra todos los servidores DNS. Riesgo interesante de comercio. Me encantaría saber cuál es su literatura de marketing y amp; Los acuerdos de nivel de servicio contractuales dicen sobre la redundancia y la disponibilidad de su infraestructura.

En cualquier caso, sería aconsejable tener servidores DNS alojados con más de un proveedor.

    
respondido por el Trey Blalock 22.10.2016 - 07:55
fuente

Lea otras preguntas en las etiquetas