Entendendo como o Facebook desapareceu da Internet
outubro 8, 2021“Facebook não pode ser para baixo, não é?”, Pensamos, por um segundo.
Hoje, às 15:51 UTC, abrimos um incidente interno intitulado “Facebook DNS lookup retornando SERVFAIL” porque estávamos preocupados que algo estava errado com nosso DNS resolver 1.1.1.1. Mas quando estávamos prestes a postar em nossa página de status público percebemos que algo mais sério estava acontecendo.
As mídias sociais rapidamente explodiram em chamas, relatando o que nossos engenheiros rapidamente confirmaram também. Facebook e seus serviços afiliados WhatsApp e Instagram foram, de fato, todos para baixo. Seus nomes de DNS pararam de resolver, e seus IPs de infraestrutura eram inalcançáveis. Era como se alguém tivesse “puxado os cabos” de seus data centers de uma só vez e desconectado-os da Internet.
Este não era um problema de DNS em si, mas falhar no DNS foi o primeiro sintoma que vimos de uma paralisação maior do Facebook.
Como isso é possível?
Atualização do Facebook
O Facebook publicou agora um post no blog dando alguns detalhes do que aconteceu internamente. Externamente, vimos os problemas de BGP e DNS descritos neste post, mas o problema realmente começou com uma mudança de configuração que afetou toda a espinha dorsal interna. Isso caiu no Facebook e em outras propriedades desaparecendo e funcionários internos do Facebook tendo dificuldade em fazer o serviço voltar.
O Facebook postou mais um post no blog com muito mais detalhes sobre o que aconteceu. Você pode ler esse post para a exibição interna e este post para a visualização externa.
Agora, vamos ao que vimos de fora.
Conheça o BGP
BGP significa Border Gateway Protocol. É um mecanismo para trocar informações de roteamento entre sistemas autônomos (AS) na Internet. Os grandes roteadores que fazem a Internet funcionar têm listas enormes e constantemente atualizadas das possíveis rotas que podem ser usadas para entregar todos os pacotes de rede aos seus destinos finais. Sem o BGP, os roteadores da Internet não saberiam o que fazer, e a Internet não funcionaria.
A Internet é literalmente uma rede de redes, e está ligada pelo BGP. O BGP permite que uma rede (digamos Facebook) anuncie sua presença para outras redes que formam a Internet. Como escrevemos o Facebook não está anunciando sua presença, os ISPs e outras redes não conseguem encontrar a rede do Facebook e, portanto, ela não está disponível.
Cada uma das redes individuais tem um ASN: um Número de Sistema Autônomo. Um Sistema Autônomo (AS) é uma rede individual com uma política de roteamento interno unificada. Um AS pode originar prefixos (digamos que eles controlam um grupo de endereços IP), bem como prefixos de trânsito (dizem que sabem como alcançar grupos específicos de endereços IP).
O ASN da Cloudflare é AS13335. Toda ASN precisa anunciar suas rotas de prefixo para a Internet usando BGP; caso contrário, ninguém saberá como se conectar e onde nos encontrar.
Nosso centro de aprendizagem tem uma boa visão geral do que são BGP e ASNs e como funcionam.
Neste diagrama simplificado, você pode ver seis sistemas autônomos na Internet e duas rotas possíveis que um pacote pode usar para ir de Início a Fim. AS1 → AS2 → AS3 sendo o mais rápido, e o AS1 → AS6 → AS5 → AS4 → AS3 sendo o mais lento, mas que pode ser usado se o primeiro falhar.
Às 15:58 UTC notamos que o Facebook tinha parado de anunciar as rotas para seus prefixos DNS. Isso significava que, pelo menos, os servidores DNS do Facebook não estavam disponíveis. Por causa desse resolvedor de DNS 1.1.1.1 da Cloudflare não poderia mais responder às consultas pedindo o endereço 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>
Enquanto isso, outros endereços IP do Facebook permaneceram roteados, mas não foram particularmente úteis, uma vez que sem o DNS Facebook e serviços relacionados estavam efetivamente indisponíveis:
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>
Acompanhamos todas as atualizações e anúncios do BGP que vemos em nossa rede global. Em nossa escala, os dados coletados nos dão uma visão de como a Internet está conectada e onde o tráfego deve fluir de e para todos os lugares do planeta.
Uma mensagem BGP UPDATE informa um roteador de quaisquer alterações que você fez em um anúncio de prefixo ou retira totalmente o prefixo. Podemos ver claramente isso no número de atualizações que recebemos do Facebook ao verificar nosso banco de dados BGP séries temporâneas. Normalmente este gráfico é bastante silencioso: o Facebook não faz muitas alterações em sua rede minuto a minuto.
Mas por volta das 15:40 UTC vimos um pico de mudanças de roteamento do Facebook. Foi quando o problema começou.
Se dividirmos essa visão por anúncios de rotas e saques, teremos uma ideia ainda melhor do que aconteceu. As rotas foram retiradas, os servidores DNS do Facebook ficaram offline, e um minuto após o problema ocorreu, os engenheiros da Cloudflare estavam em uma sala perguntando por que o 1.1.1.1.1 não conseguia resolver facebook.com e se preocupando que de alguma forma era uma falha em nossos sistemas.
Com esses saques, o Facebook e seus sites efetivamente se desligaram da Internet.
DNS é afetado
Como consequência direta disso, os resolvedores de DNS em todo o mundo pararam de resolver seus nomes de domínio.
➜ ~ 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
Isso acontece porque o DNS, como muitos outros sistemas na Internet, também tem seu mecanismo de roteamento. Quando alguém digita a URL https://facebook.com no navegador, o resolve DNS, responsável por traduzir nomes de domínio em endereços IP reais para se conectar, verifica primeiro se ele tem algo em seu cache e o usa. Se não, ele tenta obter a resposta dos servidores de nome de domínio, normalmente hospedados pela entidade que a possui.
Se os servidores de nome não forem bem-intencionados ou não responderem por algum outro motivo, então um SERVFAIL será devolvido, e o navegador emite um erro ao usuário.
Mais uma vez, nosso centro de aprendizagem fornece uma boa explicação sobre como o DNS funciona.
Devido ao Facebook parar de anunciar suas rotas de prefixo DNS através do BGP, nossos e todos os outros resolvedores de DNS não tinham como se conectar aos seus servidores de nome. Consequentemente, 1.1.1.1, 8.8.8.8, e outros grandes soluções públicas de DNS começaram a emitir (e cache) respostas SERVFAIL.
Mas isso não é tudo. Agora, o comportamento humano e a lógica da aplicação entra em ação e causa outro efeito exponencial. Segue-se um tsunami de tráfego adicional de DNS.
Isso aconteceu em parte porque os aplicativos não aceitam um erro para uma resposta e começam a tentar novamente, às vezes agressivamente, e em parte porque os usuários finais também não aceitam um erro por uma resposta e começam a recarregar as páginas, ou matar e relançar seus aplicativos, às vezes também agressivamente.
Este é o aumento de tráfego (em número de solicitações) que vimos em 1.1.1.1:
Então, agora, como o Facebook e seus sites são tão grandes, temos soluções de DNS em todo o mundo lidando com 30x mais consultas do que o habitual e potencialmente causando problemas de latência e tempo limite para outras plataformas.
Felizmente, o 1.1.1.1 foi construído para ser gratuito, privado, rápido (como o monitor independente DNSPerf pode atestar), e escalável, e conseguimos continuar atendendo nossos usuários com impacto mínimo.
A grande maioria dos nossos pedidos de DNS continuou a ser resolvida em menos de 10ms. Ao mesmo tempo, uma fração mínima de percentis p95 e p99 viu tempos de resposta aumentados, provavelmente devido aos TTLs expirados tendo que recorrer aos servidores de nomes do Facebook e tempo limite. O limite de tempo limite de tempo limite de 10 segundos do DNS é bem conhecido entre os engenheiros.
Impactando outros serviços
As pessoas procuram alternativas e querem saber mais ou discutir o que está acontecendo. Quando o Facebook se tornou inalcançável, começamos a ver consultas de DNS aumentadas no Twitter, Signal e outras plataformas de mensagens e redes sociais.
Também podemos ver outro efeito colateral dessa inalcançável em nosso tráfego WARP de e para o ASN 32934 afetado do Facebook. Este gráfico mostra como o tráfego mudou de 15:45 UTC para 16:45 UTC em comparação com três horas antes em cada país. Em todo o mundo, o tráfego WARP de e para a rede do Facebook simplesmente desapareceu.
A Internet
Os eventos de hoje são um lembrete gentil de que a Internet é um sistema muito complexo e interdependente de milhões de sistemas e protocolos trabalhando juntos. Essa confiança, padronização e cooperação entre entidades estão no centro de fazê-lo funcionar para quase cinco bilhões de usuários ativos em todo o mundo.
Atualização
Por volta das 21:00 UTC vimos a atividade BGP renovada da rede do Facebook que atingiu o pico às 21:17 UTC.
Este gráfico mostra a disponibilidade do nome DNS ‘facebook.com’ no DNS resolver 1.1.1.1.1 da Cloudflare. Ele deixou de estar disponível por volta das 15:50 UTC e retornou às 21:20 UTC.
Sem dúvida, os serviços do Facebook, WhatsApp e Instagram levarão mais tempo para entrar online, mas a partir das 21:28 UTC o Facebook parece estar reconectado à Internet global e ao DNS trabalhando novamente.
Fonte: Entendendo como o Facebook desapareceu da Internet (cloudflare.com)
