Ayer a las 16:51 UTC, el proveedor Cloudflare abrió un incidente interno titulado “Búsqueda de DNS de Facebook que devuelve SERVFAIL” porque les preocupaba que algo estuviera mal su servicio de DNS 1.1.1.1. Pero cuando estaban a punto de publicarlo en su página, se dieron cuenta de que estaba sucediendo algo más serio: Facebook y sus servicios afiliados WhatsApp e Instagram estaban caídos y se manejaban muchas teorías conspirativas.
Aclaración: esto no tiene nada que ver con el robo de datos sufrido por Facebook en septiembre.
Sus nombres DNS dejaron de resolverse y sus IP de infraestructura eran inalcanzables. Era como si alguien hubiera “desconectado los cables” de Internet.
¿Cómo es eso posible? Por BGP
BGP son las siglas de Border Gateway Protocol. Es un mecanismo para intercambiar información de enrutamiento entre Sistemas Autónomos (AS) en Internet. Los grandes enrutadores que hacen que Internet funcione tienen listas enormes y constantemente actualizadas de las posibles rutas que se pueden utilizar para entregar cada paquete de red a sus destinos finales. Sin BGP, los enrutadores de Internet no sabrían qué hacer e Internet no funcionaría.
Internet es literalmente una red de redes y está unida por BGP. BGP permite que una red (digamos Facebook) anuncie su presencia a otras redes que forman Internet. Lo que sucedió es que Facebook dejó de anunciar su presencia, los ISP y otras redes no pueden encontrar la red de Facebook y, por lo tanto, no está disponible… No existe.
Cada una de las redes tiene un ASN: un número de sistema autónomo. Un sistema autónomo (AS) es una red individual con una política de enrutamiento interna unificada. Un AS puede originar prefijos (digamos que controlan un grupo de direcciones IPs), así como prefijos de tránsito (digamos que saben cómo llegar a grupos específicos de direcciones IPs).
Por ejemplo, el ASN de Facebook es 32934. Cada ASN necesita anunciar sus rutas de prefijo a Internet usando BGP; de lo contrario, nadie sabrá cómo conectarse y dónde encontrar un servidor. Este centro de aprendizaje tiene una buena descripción general de lo que son BGP y ASN y cómo funcionan.
Por ejemplo, en este diagrama simplificado, puede ver seis sistemas autónomos en Internet y dos rutas posibles que un paquete puede usar para ir de principio a fin. AS1 → AS2 → AS3 es el más rápido, y AS1 → AS6 → AS5 → AS4 → AS3 es el más lento, pero se puede usar si el primero falla.
El gran problema de Facebook podría ser que todos sus servicios se ejecutan en una infraestructura de back-end compartida, lo que crea un “punto único de falla” que produce una caída en cascada. Por este mismo motivo, las interrupciones globales son una de las principales desventajas de un sistema centralizado como el de DNS (y la red de Facebook misma).
A las 16:58 UTC, Facebook había dejado de anunciar las rutas a sus prefijos DNS. Eso significaba que, al menos, los servidores DNS de Facebook no estaban disponibles. Debido a esto, el sistema de resolución de DNS ya no podía responder a las consultas que solicitaban la dirección IP de facebook.com o instagram.com.
route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>
route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>
Mientras tanto, otras direcciones IP de Facebook permanecieron enrutadas, pero no fueron particularmente útiles, ya que sin DNS, Facebook y los servicios relacionados no estaban efectivamente disponibles.
Un mensaje de BGP UPDATE informa al enrutador de cualquier cambio que haya realizado y esto se puede ver claramente en la cantidad de actualizaciones recibidas de Facebook. Normalmente, este gráfico es bastante silencioso porque no es normal que Facebook realice muchos cambios en su red minuto a minuto. Pero alrededor de las 15:40 UTC se puede ver un pico de cambios en el enrutamiento de Facebook. Fue entonces cuando empezó el problema.
Si dividimos esta vista por anuncios de rutas y retiros, tenemos una idea aún mejor de lo que sucedió. Se retiraron las rutas, los servidores DNS de Facebook se desconectaron y facebook.com “dejó de existir”. Como consecuencia directa de esto, los resolutores de DNS de todo el mundo también dejaron de resolver sus nombres de dominio.
~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
Esto sucede porque el DNS, como muchos otros sistemas en Internet, también tiene su mecanismo de enrutamiento. Cuando alguien escribe la URL https://facebook.com en el navegador, el DNS, responsable de traducir los nombres de dominio a direcciones IP reales para conectarse, primero verifica si tiene algo en su caché y lo usa. De lo contrario, intenta obtener la respuesta de los servidores de nombres de dominio, normalmente alojados por la entidad propietaria.
Si no se puede acceder a los servidores de nombres o no responden por algún otro motivo, se devuelve un SERVFAIL y el navegador envía un error al usuario. Esta es una buena explicación sobre cómo funciona el DNS.
Debido a que Facebook dejó de anunciar sus rutas de prefijo DNS a través de BGP, todos los resolutores de DNS no tenían forma de conectarse a sus servidores de nombres. En consecuencia, 1.1.1.1, 8.8.8.8 y otros importantes solucionadores de DNS públicos comenzaron a emitir (y almacenar en caché) respuestas SERVFAIL.
Pero eso no es todo. Ahora el comportamiento humano y la lógica de la aplicación entran en juego y provocan otro efecto exponencial. Sigue un tsunami de tráfico DNS adicional. Esto sucedió en parte porque las aplicaciones no aceptarán un error como respuesta y comenzarán a intentarlo de nuevo, a veces de manera agresiva, y en parte porque los usuarios finales tampoco aceptarán un error como respuesta y comenzarán a recargar las páginas, o matarán y relanzarán sus aplicaciones, a veces también de forma agresiva.
Este es el aumento de tráfico (en número de solicitudes) que se puede ver aquí vimos en 1.1.1.1:
Impactando otros servicios
La gente busca alternativas y quiere saber más o discutir lo que está sucediendo. Cuando Facebook se volvió inalcanzable, se vió un aumento de las consultas de DNS a Twitter, Telegram, Signal y otras plataformas de mensajería y redes sociales.
Los eventos de hoy son un suave recordatorio de que Internet es un sistema muy complejo e interdependiente de millones de sistemas y protocolos que trabajan juntos. Esa confianza, estandarización y cooperación entre entidades son fundamentales para que funcione para casi cinco mil millones de usuarios activos en todo el mundo.
La explicación oficial de Facebook
“Nuestros equipos de ingeniería descubrieron que los cambios de configuración en los routers troncales que coordinan el tráfico de red entre nuestros data centers causaron problemas que interrumpieron esta comunicación. Esta interrupción del tráfico de la red tuvo un efecto en cascada en la forma en que se comunican nuestros centros de datos, lo que paralizó nuestros servicios. Tampoco tenemos evidencia de que los datos del usuario se hayan visto comprometidos como resultado de este tiempo de inactividad”, explicó el ingeniero en un comunicado publicado en el sitio oficial de la compañía.
Fuente: Cloudflare