- El 16 de abril de 2025, varias interrupciones en los servicios de Zoom comenzaron por una falla en la resolución del dominio zoom.us, lo que impidió que clientes en EE. UU. y otras regiones internacionales accedieran al servicio
- La interrupción fue reportada a las 11:25 PDT y resuelta a las 13:12; se vieron afectados el portal web de Zoom Meetings, Zoom Phone, Zoom CX y Zoom Website
- No hubo fallas internas de producto, seguridad o red en Zoom, ni un ataque DDoS; la causa fue un error de comunicación entre Markmonitor y GoDaddy Registry
- Los usuarios que ya estaban dentro de una reunión o llamada de Zoom Phone no se vieron afectados, pero las solicitudes para iniciar, unirse o programar podían fallar porque requerían una consulta DNS
- Zoom, Markmonitor y GoDaddy eliminaron el bloqueo del servidor para restaurar el servicio y, para evitar recurrencias, aplicaron un registry lock al dominio zoom.us
Alcance y tiempo de la interrupción
- La interrupción afectó el acceso a varios servicios de Zoom debido a una falla en la resolución del dominio zoom.us
- El incidente de servicio fue reportado el 16 de abril de 2025 a las 11:25 a. m. PDT y resuelto a la 1:12 p. m. PDT
- Clientes en EE. UU. y otras regiones internacionales no pudieron acceder a los servicios de Zoom
- Servicios afectados:
- Zoom Meetings
- Portal web de Zoom Phone - Global
- Portal web de Zoom CX - Global
- Portal web de Zoom Website
Causa y proceso de recuperación
- Los servidores de nombres de dominio de Zoom estaban respondiendo normalmente a las solicitudes
- La causa real fue un server block en GoDaddy Registry, que dejó al dominio zoom.us en un estado no utilizable
- Este bloqueo se originó por un error de comunicación entre Markmonitor, el registrador del dominio de Zoom, y GoDaddy Registry
- Como resultado, GoDaddy Registry terminó por error el dominio zoom.us
- Durante la interrupción no hubo fallas internas de producto, seguridad o red en Zoom, ni ataques DDoS
- Los usuarios finales que ya habían entrado a reuniones de Zoom o llamadas de Zoom Phone no se vieron afectados
- Las acciones de iniciar, unirse y programar reuniones requerían una consulta DNS, por lo que no podían completarse con normalidad
- Zoom, Markmonitor y GoDaddy identificaron y eliminaron el bloqueo del servidor para restaurar el servicio del dominio zoom.us
- Como las entradas DNS se almacenan en caché en varias capas y tienen un TTL configurado, la propagación por toda la infraestructura de internet tomó algunos minutos más después de reactivar el dominio
Prevención de recurrencias y acciones para usuarios
- GoDaddy Registry y Markmonitor aplicaron un registry lock al dominio zoom.us para evitar que esto vuelva a ocurrir
- Este bloqueo restringe la aplicación de comandos de bloqueo de servidor al dominio zoom.us
- Los usuarios que sigan teniendo problemas de conexión pueden vaciar la caché DNS y volver a conectarse
- Windows:
ipconfig /flushdns - Mac:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Windows:
1 comentarios
Opiniones de Hacker News
El valor del servicio de MarkMonitor parece haber caído mucho. MarkMonitor se promociona como “registrador acreditado por ICANN y líder de la industria desde 1999”.
La razón para pagarle caro a MarkMonitor es que maneje dominios importantes y no cometa errores como este; aquí no debería haber habido margen para que interviniera GoDaddy.
Si eso no les gustaba, debieron haber querido un .com operado por Verisign.
En cambio, Apple usa “Nom-iq Ltd. dba COM LAUDE”, las empresas de Meta usan RegistrarSafe, y Nvidia usa SafeNames.
Si el mismo problema le hubiera pasado a una startup pequeña, siento que GoDaddy ni siquiera les habría hecho caso.
Por ejemplo, cuando se necesita una dirección física dentro de ese país, MarkMonitor puede tener oficinas en varios países, cumplir ese requisito y luego venderles dominios ccTLD a sus clientes.
La legalidad de esta estructura me parece algo dudosa, aunque no soy abogado.
Para convencer a mi empleador de entonces de dejar Zoom, decidí ver cuántas vulnerabilidades de seguridad podía encontrar en 2 o 3 horas.
Con solo binwalk e información de fuentes públicas encontré 12 bugs confirmados en ese tiempo, y el más grave era que el correo de restablecimiento de contraseña de la cuenta de GoDaddy de zoom.us era la cuenta personal de Gmail de Eric S Yuan, el CEO.
Al intentar restablecer la contraseña de Gmail, vi que no tenía autenticación de dos factores y que solo requería dos preguntas de recuperación, ciudad natal y número de teléfono; con información pública pude obtener las respuestas, recibir el enlace de restablecimiento y llegar hasta el control del dominio zoom.us.
No pude encontrar ni a una sola persona del equipo de seguridad que pudiera explicarlo en inglés, y Zoom tardó 3 meses en confirmarlo y pagar un total de 800 dólares en bug bounty.
Al menos gracias a eso mi empleador dejó Zoom.
Supongo que habrá sido en los primeros días, cuando Zoom apenas empezaba a volverse popular.
GoDaddy es una organización demasiado incompetente como para dejarle administrar algo importante.
Para evitar que pasen estas cosas se le paga mucho dinero a MarkMonitor, y MarkMonitor debería haber tenido un responsable dedicado y canales de comunicación directos con GoDaddy.
Aunque GoDaddy haya procesado algo distinto de lo solicitado, esto también fue un gran error del lado de MarkMonitor.
Hace algunos años usé un dominio de nivel superior .us, pero al final concluí que no debía dejar que mi dominio dependiera de un código de país.
Esa es también la razón por la que no uso .io.
No quiero decir que esto sea imposible en los dominios genéricos de nivel superior, pero me pregunto por qué alguien pondría su marca en manos de un gobierno de esa manera.
Bajo ese criterio, .eu podría ser un candidato mejor, pero basta preguntarles a los antiguos dueños británicos de dominios cómo les fue con eso.
Los dominios genéricos de nivel superior solo agregan una capa adicional de incompetencia llamada empresa operadora, y el gobierno del país donde está esa empresa también puede intervenir.
Por ejemplo, .nl tampoco lo operan funcionarios del gobierno neerlandés; si no recuerdo mal, lo opera una organización sin fines de lucro que iniciaron unas personas en los años 80.
Incluso un dominio de nivel superior “genérico” como .com queda de todos modos bajo jurisdicción estadounidense.
Todavía no hay una decisión tomada, pero no hace falta tener esa incertidumbre colgando sobre la cabeza.
Como vivo aquí y seguiré viviendo aquí, me parece adecuado usar un dominio nacional de nivel superior para representarme a mí y a mi trabajo.
.com en sí mismo también está bajo jurisdicción estadounidense y lo opera Verisign.
Por este tipo de posibilidad, Fastmail compró fastmail.com y migró desde su antiguo dominio fastmail.fm.
.fm era interesante, pero sufrieron varias caídas de los servidores .fm que los dejaron sin conexión, y desde que pasaron a .com no han tenido ese problema.
Me sorprende que haya tantas interrupciones de servicio causadas por tratar con GoDaddy.
GoDaddy adquirió el negocio de registros de Neustar en 2020, cuando todos estaban distraídos con otras cosas.
Yo no soy cliente, no pienso comprar dominios desde el extranjero, y no tengo una opinión firme sobre GoDaddy aparte de que no me gusta el nombre.
He oído muchas historias de terror, pero también me pregunto si esto es una reacción refleja inmediata.
Zoom debería tener dominios de segundo y tercer nivel para las llamadas que hace el cliente, y también diversificar registradores e infraestructura de hosting.
Incluso estaría bien tener direcciones IP anycast de respaldo para descubrimiento de servicios.
Considerando lo que pagan empresas como la nuestra, sería razonable esperar ese nivel de preparación de ingeniería, y todavía pueden corregirlo.
#HugOps para el personal que está trabajando de noche respondiendo al incidente.
Si el CEO de Zoom dijera: “Queremos recibir créditos de SLA por la caída mundial que ustedes provocaron”, GoDaddy probablemente respondería: “Lo sentimos. Podemos darles un cupón único de 10 dólares de descuento para su próxima compra o renovación”.
La mayoría de las empresas espera que una llamada de Zoom para disculparse sea suficiente para retener a los clientes, y en la práctica casi siempre funciona.
No se habla lo suficiente de lo grande que es la asimetría entre los créditos de SLA y el impacto en ingresos ante la falla de un proveedor específico, ni de cómo eso debería reflejarse en la decisión de construir vs. comprar.
Hacerlo implicaría que, en la operación normal, casi no hay margen de ganancia.
Un SLA es más útil como mecanismo para salir de un contrato de largo plazo con un proveedor poco confiable que como forma de compensar los ingresos perdidos por una caída.
GoDaddy lleva años siendo pésimo, y para mí el punto de quiebre fue la forma en que bloquearon la API de ACME si no eras un cliente de primer nivel.
Nunca confiaría en ellos.
Si quieres eso, puedes comprarle a una aseguradora una póliza a la medida para ese incidente y pagar un costo anual similar.
También en construir vs. comprar, lo hecho internamente a menudo es peor que lo comprado.
Los productos comprados se corrigen constantemente gracias a reportes de bugs de clientes de todo el mundo, mientras que las herramientas internas rara vez son sometidas a tanto stress testing ni curtidas en batalla al mismo nivel.
Parece que pasó algo del lado de MarkMonitor. Es posible que hayan marcado por error a zoom.us como suplantación de marca, presentado una denuncia de derechos de autor ante GoDaddy, que opera el dominio de nivel superior .us, y que GoDaddy haya suspendido el dominio en respuesta a esa denuncia.
Si se hubiera mencionado a MarkMonitor pero no tuviera ninguna otra relación, la teoría de la denuncia de derechos de autor sería más plausible.
Cuando ocurrió esta caída, pensé que por fin habían hecho la “migración” y que algo había salido mal.
Hoy también escuché que la cuenta de Twitter @zoom_us fue eliminada.
Las denuncias por infracción de derechos de autor pueden ser abusadas, y de hecho lo son, en GitHub, YouTube, etc.
Me pregunto desde cuándo se volvió socialmente normal partir de la presunción de culpabilidad.
GoDaddy no es el gobierno, pero esto es inaceptable.
A cualquier persona le habría bastado mirar el dominio durante 3 segundos para darse cuenta de que era un falso positivo y que no debía eliminarse.
Análisis de la caída por ThousandEyes: https://www.thousandeyes.com/blog/zoom-outage-analysis-april...
Por ejemplo, explica qué es DNS, pero no por qué ocurrió la caída; solo presenta una cronología con contexto útil para alguien que todavía está aprendiendo qué es DNS y cómo funciona.