Come Facebook è scomparso da Internet

“Facebook non può essere down, vero?”, abbiamo pensato per un secondo.

Oggi alle 15:51 UTC, abbiamo aperto un incidente interno intitolato "Ricerca DNS di Facebook che restituisce SERVFAIL" perché eravamo preoccupati che qualcosa non andasse con il nostro resolver DNS 1.1.1.1. Ma mentre stavamo per postare sulla nostra pagina di stato pubblico ci siamo resi conto che stava succedendo qualcos'altro di più serio.

I social media sono rapidamente andati a fuoco, riportando ciò che anche i nostri ingegneri hanno rapidamente confermato. Facebook e i suoi servizi affiliati WhatsApp e Instagram erano, infatti, tutti down. La risoluzione dei loro nomi DNS è stata interrotta e gli IP della loro infrastruttura erano improvvisamente irraggiungibili. È stato come se qualcuno avesse "tirato i cavi" dai datacenter tutti in una volta e li avesse disconnessi da Internet.

Non è stato un problema DNS in sé, ma il mancato DNS è stato il primo sintomo che abbiamo visto di un'interruzione più ampia delle attività di Facebook.

Com'è stato possibile?

Facebook ha appena pubblicato un post sul blog fornendo dettagli di cosa è successo internamente. Dal di fuori, abbiamo visto i problemi BGP e DNS descritti in questo post, ma in realtà il problema è iniziato con una modifica della configurazione che ha interessato l'intera dorsale interna. Ciò è precipitato su Facebook e altre proprietà che sono scomparse e il personale interno a Facebook ha avuto difficoltà a far ripartire il servizio.

Facebook ha pubblicato un ulteriore post con molti più dettagli su quello che è successo. Puoi leggere quel post per sapere cosa è successo all'interno e questo post per quello che si è visto da fuori.

Consideriamo cosa abbiamo visto da fuori.

BGP sta per Border Gateway Protocol ed è un meccanismo per scambiare informazioni di routing tra sistemi autonomi (AS) su Internet. I grandi router che fanno funzionare Internet hanno enormi elenchi costantemente aggiornati dei possibili percorsi che possono essere utilizzati per consegnare ogni pacchetto di rete alle loro destinazioni finali. Senza BGP, i router Internet non saprebbero cosa fare e Internet non funzionerebbe.

Internet è letteralmente una rete di reti, tutte tenute insieme da BGP. BGP consente a una rete (ad esempio Facebook) di pubblicizzare la propria presenza ad altre reti che formano l'Internet. Mentre scriviamo Facebook non sta pubblicizzando la sua presenza, gli ISP e altre reti non riescono a trovare la rete di Facebook e quindi non è disponibile.

Ogni singola rete ha un proprio ASN (Autonomous System Number), ovvero un numero sistema autonomo. Un sistema autonomo (AS, Autonomous System) è una singola rete con una con una politica di routing interna unificata. Un AS può originare prefissi (che controllano un gruppo di indirizzi IP), così come prefissi di transito (che sanno come raggiungere gruppi specifici di indirizzi IP).

L'ASN di Cloudflare è AS13335. Ogni ASN ha bisogno di annunciare le sue route di prefisso a Internet utilizzando BGP altrimenti nessuno saprà come collegarsi e dove trovarci.

Il nostro Centro di apprendimento sa cosa sono BGP e gli ASN e come funzionano.

In questo diagramma semplificato, sono riportati sei sistemi autonomi su Internet e due possibili route che un pacchetto può utilizzare per andare dall'inizio alla fine. AS1 → AS2 → AS3 è il percorso più rapido mentre AS1 → AS6 → AS5 → AS4 → AS3 è il più lento, ma può essere utilizzato in caso di errore del primo.

Alle 15:58 UTC abbiamo notato che Facebook aveva smesso di annunciare i percorsi ai suoi prefissi DNS. Ciò ha fatto sì che, almeno, i server DNS di Facebook non fossero disponibili. Per questo motivo, il resolver DNS 1.1.1.1 di Cloudflare non è stato più in grado di rispondere alle domande che richiedevano l'indirizzo IP di facebook.com.

Nel frattempo, altri indirizzi IP di Facebook sono rimasti instradati ma non sono stati particolarmente utili poiché senza DNS Facebook e i relativi servizi non erano effettivamente disponibili:

Teniamo traccia di tutti gli aggiornamenti e gli annunci BGP che vediamo nella nostra rete globale. Su scala, i dati che raccogliamo ci danno una visione di come Internet è connesso e dove il traffico deve fluire da e verso ogni parte del pianeta.

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>

Un messaggio BGP UPDATE informa un router di eventuali modifiche apportate a un annuncio di prefisso o rimuove completamente il prefisso. Possiamo vederlo chiaramente nel numero di aggiornamenti che abbiamo ricevuto da Facebook durante il controllo del nostro database BGP delle serie temporali. Normalmente questo grafico è abbastanza silenzioso: Facebook non apporta molte modifiche alla sua rete minuto per minuto.

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>

Ma intorno alle 15:40 UTC abbiamo visto un picco di modifiche al routing da Facebook. Ed è qui che sono iniziati i problemi.

Se dividiamo questa vista per annunci di route e ritiri, abbiamo un'idea ancora migliore di quello che è successo. Le route sono state ritirate, i server DNS di Facebook sono andati offline e un minuto dopo che si è verificato il problema, gli ingegneri di Cloudflare erano in una stanza chiedendosi perché 1.1.1.1 non riuscisse a risolvere facebook.com e preoccupandosi che fosse in qualche modo un guasto con i nostri sistemi.

Con quei ritiri, Facebook e i suoi siti si erano effettivamente disconnessi da Internet.

Come diretta conseguenza, i resolver DNS di tutto il mondo hanno smesso di risolvere i loro nomi di dominio.

Questo accade perché il DNS, come molti altri sistemi su Internet, ha anche il suo meccanismo di routing. Quando qualcuno digita l'URL https://facebook.com nel browser, il resolver DNS, responsabile della traduzione dei nomi di dominio in indirizzi IP effettivi a cui connettersi, verifica innanzitutto se ha qualcosa nella sua cache e lo utilizza. In caso contrario, tenta di ottenere la risposta dai server dei nomi di dominio, in genere ospitati dall'entità che lo possiede.

Se i server dei nomi non sono raggiungibili o non rispondono per altri motivi, viene restituito un SERVFAIL e il browser invia un errore all'utente.

➜  ~ 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

Di nuovo, il nostro centro di apprendimento fornisce una buona spiegazione di come funziona DNS.

A causa dell'interruzione da parte di Facebook dell'annuncio dei percorsi del prefisso DNS tramite BGP, i resolver DNS nostri e di tutti gli altri non avevano modo di connettersi ai loro server dei nomi. Di conseguenza, 1.1.1.1, 8.8.8.8 e tutti gli altri principali resolver DNS pubblici hanno iniziato a emettere (e a memorizzare nella cache) risposte SERVFAIL.

Ma non è tutto. A questo punto entrano in gioco il comportamento umano e la logica applicativa, che provocano un altro effetto esponenziale. Segue uno tsunami di traffico DNS aggiuntivo.

Ciò è accaduto in parte perché le app non accettano un errore per una risposta e iniziano a riprovare, a volte in modo aggressivo, e in parte perché anche gli utenti finali non accettano un errore per una risposta e iniziano a ricaricare le pagine o a terminare e riavviare le loro app, a volte anche in modo aggressivo.

Questo è l'aumento del traffico (in numero di richieste) che abbiamo visto il 1.1.1.1:

Quindi ora, poiché Facebook e i suoi siti sono così grandi, abbiamo risolutori DNS in tutto il mondo che gestiscono 30 volte più query del solito e potenzialmente causano problemi di latenza e timeout su altre piattaforme.

Fortunatamente, 1.1.1.1 è stato progettato in modo da essere Gratuito, Privato, Rapido (come il monitor DNS DNSPerf indipendente può attestare) e scalabile, e siamo stati in grado di continuare a fornire assistenza ai nostri utenti con un impatto minimo.

La stragrande maggioranza delle nostre richieste DNS ha continuato a risolversi in meno di 10 ms. Allo stesso tempo, una frazione minima dei percentili p95 e p99 ha visto un aumento dei tempi di risposta, probabilmente a causa dei TTL scaduti che hanno dovuto ricorrere ai server dei nomi di Facebook e al timeout. Il limite di timeout DNS di 10 secondi è ben noto agli ingegneri.

Le persone cercano alternative e vogliono saperne di più o discutere di cosa sta succedendo. Quando Facebook è diventato irraggiungibile, abbiamo iniziato a vedere un aumento delle query DNS su Twitter, Signal e altre piattaforme di messaggistica e social media.

Possiamo anche vedere un altro effetto collaterale di questa irraggiungibilità nel nostro traffico WARP da e verso l'ASN 32934 di Facebook interessato. Questo grafico mostra come il traffico è cambiato dalle 15:45 UTC alle 16:45 UTC rispetto a tre ore prima in ogni paese. In tutto il mondo il traffico WARP da e verso la rete di Facebook è semplicemente scomparso.

Gli eventi di oggi ci ricordano dolcemente che Internet è un sistema molto complesso e interdipendente di milioni di sistemi e protocolli che lavorano insieme. La fiducia, la standardizzazione e la cooperazione tra le entità sono al centro del suo funzionamento per quasi cinque miliardi di utenti attivi in tutto il mondo.

Intorno alle 21:00 UTC abbiamo visto una rinnovata attività BGP dalla rete di Facebook che ha raggiunto il picco alle 21:17 UTC.

Questo grafico mostra la disponibilità del nome DNS "facebook.com" sul resolver DNS 1.1.1.1 di Cloudflare. Ha smesso di essere disponibile intorno alle 15:50 UTC ed è tornato alle 21:20 UTC.

Indubbiamente i servizi Facebook, WhatsApp e Instagram avevano bisogno di più tempo per tornare online, ma alle 21:28 UTC Facebook sembrava essere ricollegato a Internet globale e il DNS funzionava di nuovo.