O si lo hicieron, ¿por qué no les ayudó?
(Editar: por "secundario" quiero decir "no en Dyn")
O si lo hicieron, ¿por qué no les ayudó?
(Editar: por "secundario" quiero decir "no en Dyn")
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.
Lea otras preguntas en las etiquetas ddos