Aujourd'hui, Facebook a connu une panne
importante. Que s'est-il passé ? On sait désormais que la cause
racine était un problème de configuration des routeurs
BGP. A-t-on des détails ?
Le message d'erreur de beaucoup d'utilisateurs :
Je vous le dis tout de suite, je n'ai pas d'informations internes
à Facebook, et je n'ai pas fait une longue
enquête. N'attendez donc pas de révélations
extraordinaires. Commençons par les faits. Aujourd'hui, lundi 4
octobre vers 1550 UTC, les services de
Facebook, y compris WhatsApp et
Instagram étaient en panne. (La panne a duré
environ 6 heures.) Les utilisateurs
avaient typiquement un message faisant allusion au nom de domaine, qui ne marchait
pas.
Arrivé là, il faut se rappeler que les noms de domaine et le protocole
DNS sont critiques pour le fonctionnement de
l'Internet. Quasiment toute activité sur
l'Internet commence par une requête DNS. Si elle ne fonctionne pas,
presque rien n'est possible. Mais il faut aussi se rappeler que ce
DNS ne fonctionne pas sur un réseau
parallèle : il utilise l'Internet lui aussi, les
paquets DNS circulent dans des
paquets IP et que donc
un problème affectant IP va souvent se manifester comme un problème
DNS (puisque c'est par le DNS qu'on commence une session).
Demandons aux sondes RIPE Atlas de
trouver les serveurs de noms de facebook.com :
% blaeu-resolve -r 200 --type NS facebook.com
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 97 occurrences
[ERROR: SERVFAIL] : 48 occurrences
[] : 3 occurrences
Test #32421708 done at 2021-10-04T16:16:14Z
Une partie y arrive, probablement parce que l'information était
encore dans la mémoire de leur
résolveur. Mais ce n'est pas le cas de
toutes. En effet,
pendant la panne, les
serveurs DNS faisant
autorité pour
facebook.com ne répondaient pas. Voici la liste de ces serveurs, obtenue avec
dig en demandant à un serveur de la zone
parente,
.com (on ne
pouvait pas faire un dig « normal » puisque le
résolveur qu'il utilise aurait essayé de joindre
les serveurs en panne) :
% dig @a.gtld-servers.net. A a.ns.facebook.com.
; <<>> DiG 9.16.15-Debian <<>> @a.gtld-servers.net. A a.ns.facebook.com.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4686
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9
...
;; AUTHORITY SECTION:
facebook.com. 172800 IN NS a.ns.facebook.com.
facebook.com. 172800 IN NS b.ns.facebook.com.
facebook.com. 172800 IN NS c.ns.facebook.com.
facebook.com. 172800 IN NS d.ns.facebook.com.
...
;; ADDITIONAL SECTION:
a.ns.facebook.com. 172800 IN A 129.134.30.12
a.ns.facebook.com. 172800 IN AAAA 2a03:2880:f0fc:c:face:b00c:0:35
...
;; Query time: 16 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Mon Oct 04 18:24:55 CEST 2021
;; MSG SIZE rcvd: 833
Maintenant, demandons aux sondes RIPE Atlas
d'interroger
un de ces serveurs,
a.ns.facebook.com :
% blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com
Nameserver 129.134.30.12
[] : 3 occurrences
[TIMEOUT] : 189 occurrences
Test #32421749 done at 2021-10-04T16:25:09Z
On le voit, l'échec est total. Un peu plus tard, ça marche un peu
mieux :
% blaeu-resolve -r 200 --type NS --nameserver 129.134.30.12 --nsid facebook.com
Nameserver 129.134.30.12
[TIMEOUT] : 192 occurrences
[ERROR: SERVFAIL] : 3 occurrences
[a.ns.facebook.com. b.ns.facebook.com. c.ns.facebook.com. d.ns.facebook.com.] : 1 occurrences
Test #32421800 done at 2021-10-04T16:35:54Z
Donc, les choses sont claires : les serveurs DNS faisant autorité
ne marchaient pas. Cela explique la panne vue par les
utilisateurs. Maintenant, pourquoi ces quatre serveurs (et davantage
de machines physiques, en raison de
l'anycast) seraient-ils
tous tombés en même temps ? Il y a plusieurs hypothèses, comme une
erreur de configuration propagée automatiquement à toutes les
machines (automatiser les configurations simplifie la vie mais les
erreurs ont des conséquences plus graves). Mais on peut noter autre chose : tous ces serveurs sont
dans le même AS, le 32934, l'AS de
Facebook. Un problème de routage dans l'AS, empêchant les paquets d'arriver,
peut également empêcher les serveurs DNS de répondre. Mettre
tous
ses œufs dans le même panier est décidément une mauvaise
pratique. (Notez que ZoneMaster teste cette mauvaise
pratique et vous
alerte.) C'est un problème connu, déjà signalé par le RFC 2182, en 1997…
Creusons cette idée. Plusieurs observateurs ont noté que les
préfixes IP de Facebook ont subitement disparu de la
DFZ. Cela
explique que les serveurs DNS soient devenus injoignables. Les
sondes RIPE Atlas montrent que les traceroute
ne vont pas très loin, les préfixes n'étant plus annoncés :
% blaeu-traceroute -r 10 --format 129.134.30.12
Measurement #32421753 Traceroute 129.134.30.12 uses 10 probes
9 probes reported
Test #32421753 done at 2021-10-04T16:26:49Z
From: 89.152.207.6 2860 NOS_COMUNICACOES, PT
Source address: 89.152.207.6
Probe ID: 1001047
1 ['!', '!', '!']
2 10.137.196.193 NA NA [10.743, 10.446, 6.726]
3 10.255.48.82 NA NA [12.727, 15.974, 14.397]
4 ['*', '*', '*']
5 ['*', '*', '*']
6 ['*', '*', '*']
7 ['*', '*', '*']
8 ['*', '*', '*']
255 ['*', '*', '*']
From: 188.254.182.226 43205 BULSATCOM-BG-AS Sofia, BG
Source address: 192.168.88.13
Probe ID: 15646
1 192.168.88.1 NA NA [0.66, 0.415, 0.4]
2 188.254.180.1 43205 BULSATCOM-BG-AS Sofia, BG [1.552, 1.614, 1.231]
3 46.40.64.1 43205 BULSATCOM-BG-AS Sofia, BG [2.223, '*', '*']
4 ['*', '*', '*']
5 ['*', '*', '*']
6 ['*', '*', '*']
7 ['*', '*', '*']
8 ['*', '!', '!', '!', '!', '!', '!', '*', '*']
255 ['*', '*', '*']
Des préfixes IP plus généraux sont parfois
restés. Ainsi, le 129.134.30.0/24 d'un des
serveurs a disparu mais un /17 plus générique est resté. On voit ici
(source:
RIPEstat, le retrait du /24 puis son rétablissement
(129.134.30.0/23,
129.134.31.0/24 et bien d'autres avaient subi
le même sort) :
La panne DNS semble donc avoir été une conséquence d'une fausse
manœuvre BGP. Cela explique, par exemple, que le
service Tor de Facebook,
facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion,
ne marche pas non plus (il ne dépend pas du DNS,
.onion est spécial).
Le réseau social Instagram pendant la
panne. Bien que ses serveurs DNS répondaient parfaitement, le
serveur Web dépend de Facebook :
Plusieurs personnes sur les réseaux sociaux ont également noté
que tous les serveurs faisant autorité pour
facebook.com étaient sous le même domaine
(ns.facebook.com). Ce n'est pas forcément une
mauvaise idée. Certes, cela oblige à publier des colles (les
adresses IP des serveurs), ce qui complique l'administration. Et, si
le domaine en question a un problème, par exemple administratif,
cela frappe tous les serveurs. D'un autre côté, cela évite de
dépendre de tiers, ce qui est pourquoi cette pratique est parfois
recommandée (par
exemple par l'ANSSI).
En revanche, il était tout à fait justifié de noter que les
TTL de Facebook sont anormalement bas : 300
secondes. Cela veut dire que si la panne dure plus de 5 minutes, ce
qui a été le cas, les mémoires des résolveurs ne servent plus à
rien. La robustesse du DNS nécessite des TTL bien plus longs
(supérieurs à la durée d'une panne typique).
Ah, et puis rappelez-vous que Facebook n'est pas tout
l'Internet : tous les autres services fonctionnaient parfaitement
(sauf ceux qui avaient choisi de dépendre de Facebook).
Articles dans les médias :
La panne vue par l'excellent service de vérification DNSviz (le même résultat, en ligne) :
