El pasado día 4 a las 16:51 UTC, se produjo una caída mundial de Facebook, Instagram y WhatsApp, sus nombres DNS dejaron de resolverse y sus IP de infraestructura eran inalcanzables. Era como si alguien hubiera “desconectado los cables” de Internet.
¿Qué sucedió?
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 (por ejemplo, Facebook) anuncie su presencia a otras redes que forman Internet. Lo que sucedió es que Facebook dejó de anunciar su presencia, y los ISP y otras redes no pudieron encontrar la red de Facebook y, por lo tanto, no estaba disponible… No existía.
Además, cada una de las redes tiene un ASN: un número de sistema autónomo (AS). Un sistema autónomo es una red individual con una política de enrutamiento interna unificada. Un AS puede originar prefijos (por ejemplo, que controlan un grupo de direcciones IPs), así como prefijos de tránsito (por ejemplo, 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. El centro de aprendizaje de Cloudflare tiene una buena descripción general de lo que son BGP y ASN y cómo funcionan.
Por ejemplo, en el diagrama simplificado de arriba, se pueden 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 fallo” 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).
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 pudo responder a las consultas que solicitaban la dirección IP de facebook.com o instagram.com.
Internet es literalmente una red de redes y está unida por BGP. BGP permite que una red (por ejemplo, Facebook) anuncie su presencia a otras redes que forman Internet. Lo que sucedió es que Facebook dejó de anunciar su presencia, y los ISP y otras redes no pudieron encontrar la red de Facebook y, por lo tanto, no estaba disponible… No existía.
Además, cada una de las redes tiene un ASN: un número de sistema autónomo (AS). Un sistema autónomo es una red individual con una política de enrutamiento interna unificada. Un AS puede originar prefijos (por ejemplo, que controlan un grupo de direcciones IPs), así como prefijos de tránsito (por ejemplo, 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. El centro de aprendizaje de Cloudflare tiene una buena descripción general de lo que son BGP y ASN y cómo funcionan.
Por ejemplo, en el diagrama simplificado de arriba, se pueden 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 fallo” 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).
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 pudo responder a las consultas que solicitaban la dirección IP de facebook.com o instagram.com.
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 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.
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.
Esto sucede porque el DNS, como muchos otros sistemas en Internet, también tiene su mecanismo de enrutamiento. Por ejemplo, cuando alguien escribe la URL https://afsinformatica.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. Así es, muy básicamente, 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 aceptan un error como respuesta y comenzaron a intentarlo de nuevo, a veces de manera agresiva, y en parte porque los usuarios finales tampoco aceptaban un error como respuesta y comenzaron a recargar masivamente sus páginas y aplicaciones.
En el siguiente gráfico se puede ver el aumento de tráfico (en número de solicitudes) que tuvo el 1.1.1.1:
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. Así es, muy básicamente, 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 aceptan un error como respuesta y comenzaron a intentarlo de nuevo, a veces de manera agresiva, y en parte porque los usuarios finales tampoco aceptaban un error como respuesta y comenzaron a recargar masivamente sus páginas y aplicaciones.
En el siguiente gráfico se puede ver el aumento de tráfico (en número de solicitudes) que tuvo el 1.1.1.1:
