Deje de usar los nombres de dominio .IO para el tráfico de producción

Nota: Si es usuario de Stream , asegúrese de actualizar su API cliente a la última versión para una gran mejora en la confiabilidad. Para aquellos de ustedes en un cliente API personalizado, echen un vistazo a nuestra documentación REST actualizada .

La resolución de dominio es uno de los servicios troncales de Internet. Es algo en lo que normalmente pasamos muy poco tiempo pensando. Por supuesto, eso cambia cuando se rompe. Durante el año pasado, las interrupciones del dominio IO han sido la principal razón por la que nuestros clientes no pudieron usar Stream . Específicamente, la interrupción del servicio el 20 de septiembre de 2017 resultó ser un gran dolor de cabeza. Este artículo abordará los detalles detrás de los problemas de confiabilidad del nombre de dominio .IO y cómo estamos trabajando a su alrededor.

La infraestructura de Internet Domain Name System (DNS) es grande y compleja. Debido a su naturaleza descentralizada, si el problema es con su proveedor de DNS o la infraestructura de DNS más amplia, hay poco que puede hacer aparte de sentarse y esperar a que se resuelva el problema. La única solución práctica para hacer frente a las interrupciones de DNS es recurrir a un dominio de respaldo.

Esto hace que los cortes de DNS sean bastante desagradables. Muchos riesgos son complejos y costosos de mitigar y, en algunos casos, es prácticamente imposible hacerlo.

Lo que salió mal: un apagón global en el dominio de nivel superior '.io'

El 20 de septiembre de 2017, nuestro sistema monitorea y los controles de estado comenzaron a mostrar fallas intermitentes. Los pings en nuestro sitio web y los servidores de API fallaban al resolver los registros de "getstream.io" a un nombre de host válido.

La resolución del nombre de dominio es necesaria para acceder a nuestro servicio y panel central de API. Sin él, los clientes no pueden encontrar la dirección en nuestros servidores. No hace falta decir que esto fue criticado inmediatamente como crítico y recibió la atención completa de nuestro equipo.

Después de una investigación inicial, descubrimos que la resolución de cualquier registro getstream.io fallaría al azar con un error NXDOMAIN incorrecto devuelto. Posteriormente, uno de nuestros ingenieros identificó que la resolución de los dominios .io fallaría consistentemente en 2 de los 6 servidores de nombres .io. Los cuatro restantes funcionaban correctamente, lo que explicaba la aparente naturaleza aleatoria de los errores.

Una mala se ve así:

Como esto sucedió en los servidores de nombres autoritativos, nos comunicamos con nuestro proveedor de DNS y luego tratamos de ponernos en contacto con NIC.io también. Para nuestra sorpresa, descubrimos que NIC.io solo podía comunicarse por teléfono entre las 7 AM y las 12 AM UTC de lunes a viernes y no exponía ningún estado sobre el estado del servicio .

Mientras tanto, comenzamos a ver quién más se vio afectado por esta interrupción y publicamos al respecto en Twitter y en Hacker News . Mientras esperábamos a que terminara la interrupción, también aumentamos el TTL de DNS para que la cantidad de consultas de DNS fuera lo más baja posible. Poco después, recibimos una respuesta de Gandi.net informándonos que NIC.io estaba solucionando el problema.

La interrupción duró casi 2 horas, durante las cuales fallarían 1/5 de las consultas DNS para cualquier registro .getstream.io. Para algo que se encuentra frente a nuestro servicio, este es un gran problema y planteó más que algunas preguntas de nuestro lado.

¿No podría suceder esto con cualquier TLD?

Lo entendemos. A veces las cosas se rompen. De forma realista, se podría haber producido una interrupción similar en cualquier dominio de nivel superior.

Cuando comenzamos en 2014, decidimos que .io era genial desde la perspectiva de la marca. Stream es un producto técnico y nuestra audiencia es principalmente técnica, por lo que .io parecía una gran combinación. Usar el mismo dominio para las API fue más una consecuencia que una decisión reflexiva.

Es imposible estimar la probabilidad de que los servidores de nombres .com tengan el mismo tipo de interrupciones que los servidores de nombres .io. Una cosa que nos sorprendió fue que mientras aproximadamente el 20% de las resoluciones de DNS para todos los dominios .io estaban totalmente rotas , era difícil encontrar gente quejándose de eso en Twitter. De hecho, creo que fuimos uno de los primeros en tuitear esto. Si esto hubiera sucedido en todos los dominios .com, todas las fuentes de noticias habrían estado en llamas.

Lo que realmente salió mal

Desafortunadamente, descubrimos por las malas que NIC.IO no está equipado con el soporte técnico y los sistemas necesarios para administrar un dominio de nivel superior. Ser incapaz de alcanzarlos mientras ocurría una interrupción importante es inaceptable.

Si miramos más allá, no hace falta mucha investigación para descubrir que el equipo .TLD TLD cometió varios errores en los últimos años. Sólo para nombrar unos pocos:

La búsqueda de .io en HN devuelve una larga lista de interrupciones similares.

¿Cuál es la mejor solución inmediata?

Agregar un dominio .com y usarlo como el predeterminado en todos nuestros clientes de API es claramente la fruta más fácil de colgar. Por supuesto, podríamos tener el mismo problema si .com tuviera una interrupción, sin embargo, tenemos mucha más confianza en la administración detrás de .com. Está claro que el tema no solo se habría identificado antes, sino que tampoco habría llevado horas para que las personas reconocieran y corrigieran la situación.

Nuestra hoja de ruta para un servicio libre de interrupciones de DNS

Estos problemas de DNS nos hicieron detenernos y pensar en todas las formas en que un DNS puede romperse.

  1. Perdemos el control de nuestro propio dominio. Esto puede suceder de una manera alarmantemente grande de maneras:
  1. Route53 interrupción. Dado que estamos delegando getstream.io a los servidores de nombres Route53, una interrupción en sus servidores de nombres interrumpiría nuestro servicio. El corte DynDNS DDoS de 2016 es un ejemplo.
  2. .com TLD interrupción.

Como controlamos los clientes de API, implementar un mecanismo de conmutación por error es fácil. Configurar y mantener un dominio de respaldo y / o un proveedor de DNS de respaldo puede ser muy desafiante. En el primer caso, necesitaríamos mantener cientos de registros DNS sincronizados y duplicar nuestros certificados SSL; en segundo lugar, solo necesitaríamos cambiar nuestra infraestructura para no utilizar ninguna característica específica de Route53. Para eso, necesitamos mantener todos los registros DNS sincronizados en dos proveedores diferentes y asegurarnos de que no usemos ninguna característica específica del proveedor. Como cliente de AWS, este es un desafío importante ya que DNS está profundamente integrado de muchas maneras.

De cara al futuro, nuestro plan es agregar un dominio .org y encontrar un proveedor de DNS para administrar los servidores de nombres.

Conclusión

En retrospectiva, usar un dominio .IO para nuestras API centrales no fue una gran opción. La interrupción del servicio el 20 de septiembre mostró cuán severos son los problemas y la infraestructura de soporte. De acuerdo con nuestra experiencia, desaconsejaríamos usar un nombre de dominio .IO si la disponibilidad es importante.

Para solucionar el problema de DNS, el tráfico API de Stream ahora se ejecuta en un nombre de dominio .com. El sitio aún se ejecuta en .io ya que es más difícil de modificar y no tan crítico en términos de tiempo de actividad. Para mejorar aún más la fiabilidad, estamos considerando:

  • Agregar una copia de seguridad .ORG nombre de dominio.
  • Usar un proveedor de DNS de respaldo para el nombre de dominio .COM o .ORG.
  • Implementación de failover de DNS del lado del cliente en nuestros SDK.

El DNS en su conjunto es una de esas cosas que la mayoría da por sentado pero que puede causar fácilmente tiempos de inactividad y problemas serios. El uso de un TLD ampliamente usado como .com / .net / .org es la mejor y más fácil manera de garantizar la confiabilidad.

Esta es una colaboración del equipo de GetStream.io, dirigido por Tommaso Barbugli , CTO de GetStream.io. La publicación original del blog se puede encontrar en https://getstream.io/blog/stop-using-io-domain-names-for-production-traffic/ .