Comprendiendo cómo Facebook desapareció de Internet – todo lo que debes saber
Ayer a las 15:51 UTC, Cloudflare creó un incidente interno titulado “Búsqueda de DNS de Facebook que devuelve SERVFAIL”. Cloudflare pensó que algo estaba mal con el solucionador de DNS 1.1.1.1. Sin embargo, cuando estaban a punto de publicarlo en la página de estado público, la empresa se percató de que estaba sucediendo algo más serio.
Las redes sociales estallaron rápidamente en llamas, informando lo que diferentes expertos informáticos confirmaron rápidamente. De hecho, Facebook y sus servicios afiliados WhatsApp e Instagram estaban caídos. Sus nombres DNS dejaron de resolverse y sus IPs de infraestructura eran inalcanzables. Era como si alguien hubiera “sacado los cables” de sus centros de datos de una vez y los hubiera desconectado de Internet.
¿Cómo es eso posible?
Conociendo a 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.
He escuchado comparaciones de que BGP es como un sistema de oficinas de correos, un controlador de tráfico aéreo y más. Sin embargo, creo que mi explicación favorita fue la que lo comparó con un mapa. Imagina BGP como un grupo de personas que crean y actualizan mapas que te muestran cómo llegar a YouTube o Facebook.
Dado que Internet siempre está cambiando, los mapas deben actualizarse; no deseas que su ISP te lleve por un camino antiguo que ya no llega a Google. Debido a que sería una tarea enorme mapear todo el Internet en tiempo real, los sistemas autónomos comparten sus mapas. Ocasionalmente hablarán con sus vecinos de la isla para ver y copiar las actualizaciones que hayan realizado en sus mapas.
Usando mapas como analogía, es fácil imaginar cómo pueden salir mal las cosas. Cuando los consumidores obtuvieron acceso por primera vez al GPS, siempre se bromeaba acerca de que te podía llevar a un acantilado o hacia el medio del desierto. Lo mismo puede suceder con BGP: si alguien comete un error, puede terminar dirigiendo el tráfico a algún lugar al que no debes ir, lo que causará problemas. Si no se detecta, ese error terminará en el mapa de todos.
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. Durante el incidente, Facebook desapareció, los ISPs y otras redes no podían encontrar la red de Facebook y, por lo tanto, no estaba disponible.
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 IP), así como prefijos de tránsito (digamos que saben cómo llegar a grupos específicos de direcciones IP).
ASN
El ASN de Cloudflare es AS13335. Cada ASN necesita anunciar sus rutas de prefijo a Internet usando BGP; de lo contrario, nadie sabrá cómo conectarse y dónde encontrarlos
En este diagrama simplificado, puedes 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 eso se puede usar si el primero falla.
A las 15:58 UTC notamos que Facebook dejó 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 1.1.1.1 de Cloudflare ya no podía responder a las consultas que solicitaban la dirección IP de facebook.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 eran particularmente útiles ya que, sin DNS, Facebook y los servicios relacionados no estaban disponibles:
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
Not advertised to any peer
Refresh Epoch 2
3303 6453 32934
217.192.89.50 from 217.192.89.50 (138.187.128.158)
Origin IGP, localpref 100, valid, external
Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
path 7FE1408ED9C8 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
route-views>Cloudflare realiza un seguimiento de todas las actualizaciones y anuncios de BGP que observa en su red global. Los datos que recopilan les dan una idea de cómo está conectado Internet y hacia dónde debe fluir el tráfico desde y hacia todas partes del planeta.
Una actualización de BGP reporta a un enrutador de cualquier cambio que haya realizado en un anuncio de prefijo o retira por completo el prefijo. Podemos ver esto claramente en la cantidad de actualizaciones que Cloudflare recibió de Facebook al verificar la base de datos BGP de series de tiempo. Normalmente, este gráfico es bastante silencioso: Facebook no realiza muchos cambios en su red minuto a minuto.
Señales de un problema grave
Pero alrededor de las 15:40 UTC se observó 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, un minuto después de que ocurriera el problema, los ingenieros de Cloudflare estaban en una sala preguntándose por qué 1.1.1.1 no podía resolver facebook.com y preocupándose de que de alguna manera fuera una falla en sus sistemas.
Con esos retiros, Facebook y sus sitios se habían desconectado efectivamente de Internet.
El DNS se vió afectado
Como consecuencia directa de esto, los resolutores de DNS de todo el mundo 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 AEsto sucedió 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 solucionador de 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.
Debido a que Facebook dejó de anunciar sus rutas de prefijo DNS a través de BGP, los resolutores de DNS de Cloudflare y todos los demás no tenían forma de conectarse a sus nameservers. En consecuencia, 1.1.1.1, 8.8.8.8 y otros importantes resolutores de DNS públicos comenzaron a emitir (y almacenar en caché) respuestas SERVFAIL.
Pero eso no es todo. En ese momento, el comportamiento humano y la lógica de la aplicación entran en juego y provocan otro efecto exponencial. Esto conllevó un tsunami de tráfico DNS adicional.
Esto sucedió en parte porque las aplicaciones no aceptan un error como respuesta y comenzarán a intentarlo de nuevo, a veces de manera agresiva. Y, en parte porque los usuarios finales tampoco aceptan un error como respuesta y comienzan a recargar las páginas, o cierran 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 vimos en 1.1.1.1:
Solicitudes de Facebook
Entonces, debido a que Facebook y sus sitios son tan grandes, Cloudflare tiene resolutores de DNS en todo el mundo que manejan 30 veces más consultas de lo habitual. Estos pueden causar problemas de latencia y tiempo de espera en otras plataformas.
Afortunadamente, 1.1.1.1 se creó para ser gratuito, privado, rápido (como puedes atestiguar en el monitor DNS independiente DNSPerf) y escalable. Por lo tanto, Cloudflare pudo seguir prestando servicios a sus usuarios con un impacto mínimo.
La gran mayoría de las solicitudes de DNS de Cloudflare se resolvieron en menos de 10 ms. Al mismo tiempo, una fracción mínima de los percentiles p95 y p99 experimentó un aumento en los tiempos de respuesta, probablemente debido a que los TTL vencidos tuvieron que recurrir a los servidores de nombres de Facebook y al tiempo de espera. El límite de tiempo de espera de DNS de 10 segundos es bien conocido entre los ingenieros.
Impactando otros servicios
La gente busca alternativas y quiere saber más o discutir lo que está pasando. Cuando Facebook se volvió inalcanzable, comenzamos a ver un aumento de las consultas de DNS a Twitter, Signal y otras plataformas de mensajería y redes sociales.
También podemos ver otro efecto secundario de esta inaccesibilidad en el tráfico WARP hacia y desde el ASN 32934 afectado de Facebook. Este gráfico muestra cómo cambió el tráfico de las 15:45 UTC a las 16:45 UTC en comparación con tres horas antes en cada país. En todo el mundo, el tráfico WARP hacia y desde la red de Facebook simplemente desapareció.
Complejidad de Internet
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.
Actualización de parte de Facebook
Facebook realizó una publicación brindando algunos detalles de lo que sucedió internamente. Externamente, en los párrafos anteriores mencionamos los problemas de BGP y DNS, pero el problema en realidad comenzó con un cambio de configuración que afectó a toda la red troncal interna. Eso hizo que Facebook y otras propiedades desaparecieran y el personal interno de Facebook tuviera dificultades para volver a poner en funcionamiento el servicio.
