Godaddy, la empresa de dominios mas grande de la red ha estado experimentando caídas a sus servicios y miles de clientes están experimentando el mismo efecto en sus dominios.
Tabla de Contenido
La caída de Godaddy.com se debe a un ataque de Denegación de Servicio Distribuido que se ha adjudicado el colectivo hacktivista Anonymous a través de la cuenta AnonymousOwn3r y su motivación «testear la seguridad cibernética de godaddy» entre otras cosas.
NO es la primera vez que godaddy da de que hablar, en el pasado a recibido fuertes criticas por apoyar la ley SOPA y por las fotos que subió su fundador mostrando el «trofeo» de su caza a elefantes en vida de extinción.
ACTUALIZADO:
El CEO de Godaddy ha dado la cara con una pobre respuesta sobre lo sucedido:
Ayer, GoDaddy.com y muchos de nuestros clientes experimentaron cortes intermitentes del servicio que comenzaron alrededor de las 10 de la mañana (hora del pacífico). El servicio se restableció a las 4 de la tarde (hora del pacífico).
La in-disponibilidad del servicio no fue causada por agentes externos. No hemos sufrido ninguna especie de «hack» ni tampoco un ataque DDoS. Hemos determinado que la caída del servicio fue provocada por una serie de errores en nuestra red interna que corrompieron las tablas de encaminamiento de nuestros «routers». Una vez identificamos el problema, aplicamos soluciones para corregirlo y restablecer el servicio de los clientes. Además, hemos implementado medidas para evitar que este tipo de hechos vuelvan a suceder.
En ningún momento los datos de nuestros clientes han estado expuestos ni tampoco nuestros sistemas se han visto comprometidos
Lo extraño es que el anuncio de la caída se vio primero en la cuenta AnonymousOwn3r que en cualquier otro medio y desde esa cuenta se adjudicaron el ataque, también es de recalcar el énfasis puesto en negar que sufrieron un ataque y que ninguno de los datos de sus clientes fue expuesto.
Si te viste afectado por el problema de godaddy y quieres cambiar de proveedor, aquí tienes una guía de como transferir dominio de Godaddy a un servicio mejor como el de NameCheap.
Actualización 2026 — Crónica histórica: la caída de GoDaddy del 10 de septiembre de 2012 y su lección
Han pasado más de catorce años desde aquella jornada en la que GoDaddy.com —el registrador de dominios más grande del mundo en ese entonces— dejó de funcionar durante varias horas. La crónica que usted acaba de leer documenta ese día: el lunes 10 de septiembre de 2012, alrededor de las 10 de la mañana (hora del Pacífico), comenzaron las interrupciones intermitentes del servicio, y el servicio quedó completamente restablecido hacia las 4 de la tarde (hora del Pacífico), es decir, unas seis horas después.
Como recoge el artículo original, durante la caída una cuenta de Twitter bajo el nombre de Anonymous Own3r se adjudicó el incidente, afirmando actuar a título personal —no como una acción organizada por el colectivo Anonymous en general— con el objetivo declarado de «testear la seguridad cibernética» de GoDaddy. La cobertura periodística de la época confirmó ese dato: el autor de los mensajes dijo explícitamente que el ataque «no fue organizado por el colectivo Anonymous, sino por mi parte».
Al día siguiente, sin embargo, el entonces CEO interino de GoDaddy, Scott Wagner, emitió un comunicado oficial con una versión distinta: la indisponibilidad «no fue causada por agentes externos. No hemos sufrido ninguna especie de ‘hack’ ni tampoco un ataque DDoS». Según la compañía, el problema se originó en «una serie de eventos internos de red que corrompieron las tablas de datos de los routers», y en ningún momento los datos de los clientes estuvieron en riesgo ni los sistemas se vieron comprometidos. La causa real del incidente nunca quedó establecida con total certeza: lo verificable es que hubo dos versiones en conflicto —la reivindicación del usuario de Twitter y la explicación técnica de GoDaddy— y ambas quedaron registradas en la prensa de la época.
La magnitud del impacto sí está documentada: GoDaddy gestionaba entonces más de 53 millones de nombres de dominio y alojaba más de 5 millones de sitios web, y miles de sitios que dependían de sus servidores DNS quedaron inaccesibles durante la ventana de la caída. El proveedor de DNS gestionado Dyn reportó ese mismo día un aumento del 300% en solicitudes de clientes buscando migrar sus servicios.
La lección que dejó aquel lunes sigue vigente: cuando una organización concentra su dominio, su DNS, su alojamiento web y su correo en un único proveedor, una falla de ese proveedor —sea por ataque, por error interno o por cualquier causa— deja a la empresa completamente fuera de línea. La resiliencia no se trata de confiar en que el proveedor no falle, sino de estar preparado para cuando falle.
Actualización 2026 — Resiliencia de infraestructura hoy: cómo no depender de un solo proveedor
Si aquella caída de GoDaddy ocurrió en 2012, los riesgos de la concentración de servicios no han hecho sino crecer: hoy las empresas dependen aún más de la nube, del correo corporativo y de servicios SaaS alojados por terceros. Para que un incidente como el de 2012 no paralice su negocio en 2026, considere estas medidas:
Primero, implemente DNS redundante: configure servidores de nombres secundarios con un proveedor distinto al de su registrador o proveedor de hosting principal. El DNS es la «guía telefónica» de Internet; si su proveedor de DNS deja de responder, nadie llega a su sitio aunque sus servidores estén funcionando.
Segundo, active monitoreo de disponibilidad 24/7 sobre sus sitios, su correo y su DNS, con alertas inmediatas ante interrupciones. Detectar una caída en minutos —y no cuando sus clientes empiezan a llamar— es la diferencia entre una contingencia controlada y una crisis.
Tercero, mantenga un plan de contingencia documentado: credenciales de emergencia, procedimientos para cambiar DNS o redirigir servicios, y responsables designados. Un plan que solo existe «en la cabeza del administrador» no es un plan.
Cuarto, evalúe periódicamente la criticidad de cada proveedor: ¿qué pasaría con su operación si su registrador, su proveedor de hosting o su servicio de correo dejaran de funcionar durante seis horas, como ocurrió con GoDaddy en 2012?
Si necesita que un equipo especializado audite la resiliencia de su infraestructura, revise la configuración de sus servicios críticos y diseñe planes de contingencia reales, los servicios de seguridad informática de DragonJAR pueden ayudarle a identificar los puntos únicos de falla antes de que un incidente lo haga por usted.
