Product
Caída de la API de Mailgun: análisis retrospectivo de agosto de 2016
Este artículo se publicó originalmente el 12 de agosto de 2016.
Resumen
El 4 de agosto a las 22:20 UTC, Mailgun recibió una alerta sobre numerosos informes de fallos en la resolución de DNS para nuestro nombre de dominio mailgun.net, que es el dominio principal que utilizamos para nuestra API. Al empezar a investigar, descubrimos que nuestro registrador de dominios, Dynadot, había puesto nuestro dominio en estado de “client hold”.
Aproximadamente a las 22:47, Dynadot volvió a habilitar el dominio y empezamos a ver un aumento de tráfico hacia nuestro dominio api.mailgun.net. Los niveles de tráfico no alcanzaron los umbrales normales hasta las 23:17 debido a las cachés de registros DNS negativos.
Detalles
Una vez que nuestro equipo recibió la alerta de la incidencia a las 22:20 UTC, empezamos a investigar el problema confirmando que nuestros servidores de nombres autoritativos seguían respondiendo correctamente a las peticiones DNS. Confirmamos que nuestra infraestructura DNS de backend era funcional y estaba configurada correctamente, y empezamos a revisar la configuración del dominio con nuestro registrador, Dynadot.
Descubrimos que nuestro dominio se había puesto en un estado de “client hold”, lo que impide la resolución de DNS normal. No hubo ninguna comunicación previa o inmediatamente anterior a que Dynadot tomara esta acción punitiva contra nuestro dominio.
Nuestro equipo de ingeniería intentó contactar inmediatamente con la asistencia de Dynadot a través de su sistema telefónico y su asistencia por chat en directo. Durante toda la duración de esta incidencia, no pudimos contactar con su equipo de asistencia técnica por teléfono. Un mensaje pregrabado informaba de que todos los agentes de asistencia estaban ocupados y de que se volviera a llamar más tarde. Pudimos hablar con un agente a través de su sistema de chat, quien nos informó de que no podía resolver el problema y que, para levantar el bloqueo, teníamos que enviar un correo electrónico a su equipo de asistencia. El agente de asistencia insistió en que este sería el único medio disponible para resolver el problema. Durante este tiempo, también solicitamos que nos llamara un responsable e intentamos escalar el problema, pero no se nos ofreció ninguna otra opción para resolverlo.
A las 22:37, enviamos un correo electrónico a su equipo de asistencia y nuestro dominio se volvió a habilitar unos diez minutos más tarde, a las 22:47. Aunque el dominio estaba habilitado, no recibimos ninguna otra comunicación de Dynadot hasta el viernes a las 00:12 UTC, en la que indicaban que se había deshabilitado el dominio por quejas por spam, pero no recibimos ninguna información correspondiente que respaldara esta afirmación.
Solicitamos que se escalara este problema a alguien de su equipo directivo y que se nos facilitara información sobre las quejas recibidas. No hemos recibido más detalles y, hasta la fecha, no hemos hablado de esta incidencia con nadie de su equipo directivo.
Acciones y lecciones aprendidas
Nuestra relación con Dynadot existe desde 2010, es decir, antes de la adquisición de Mailgun por parte de Rackspace. Aunque históricamente hemos tenido pocos problemas a la hora de gestionar nuestros dominios, esta incidencia y, sobre todo, la imposibilidad de recibir respuestas a tiempo por parte de Dynadot hicieron que fuera necesario cambiar de proveedor de servicios. A día de hoy, hemos completado la transición al servicio corporativo de registro de dominios de Rackspace. Ofrecen un servicio ininterrumpido y ayudarán a garantizar que no vuelvan a producirse problemas similares. Aunque hayamos finalizado nuestra relación comercial, seguimos estando abiertos a hablar con Dynadot sobre este problema con la esperanza de que actualicen sus políticas y procedimientos para evitar causar problemas a otros clientes legítimos en el futuro.
