Le 4 octobre 2023, Cloudflare a rencontré des problèmes de résolution DNS à partir de 7 h UTC, et ce jusqu'à 11 h UTC. Certains utilisateurs de 1.1.1.1 ou de produits tels que WARP, Zero Trust ou d'autres résolveurs DNS tiers utilisant 1.1.1.1 peuvent avoir reçu des réponses SERVFAIL DNS à leurs requêtes, pourtant valides. Nous sommes sincèrement désolés pour cette panne. Celle-ci était due à une erreur logicielle interne et n'était aucunement le résultat d'une attaque. Cet article de blog va nous permettre de discuter de la nature de cette défaillance, des raisons pour lesquelles elle s'est produite et des mesures que nous avons mises en œuvre pour nous assurer qu'une telle situation ne se reproduise jamais.
Contexte
Dans le Domain Name System (DNS, système de noms de domaine), chaque nom de domaine existe au sein d'une zone DNS. Cette zone constitue un ensemble de noms de domaine et de noms d'hôte, contrôlés conjointement. Pour prendre un exemple, Cloudflare est responsable du nom de domaine cloudflare.com, que nous disons se trouver dans la zone « cloudflare.com ». Le domaine de premier niveau (TLD, Top-Level Domain) « .com » est détenu par un tiers et se situe dans la zone « com ». Il donne des indications sur la manière d'atteindre cloudflare.com. Au-dessus de tous les TLD se trouve la zone racine, qui donne des informations sur la marche à suivre pour joindre les TLD. La zone racine joue donc un rôle important, car elle permet la résolution de tous les autres domaines. Comme d'autres composants importants du DNS, la zone racine est signée à l'aide de DNSSEC, ce qui veut dire que la zone racine elle-même contient des signatures cryptographiques.
La zone racine est publiée sur les serveurs racines, mais il est également courant pour les opérateurs de DNS de récupérer automatiquement et de conserver une copie de la zone racine afin que les informations contenues dans cette dernière restent disponibles au cas où les serveurs racines ne seraient pas joignables. L'infrastructure DNS récursive de Cloudflare adopte cette approche, car elle permet également d'accélérer le processus de résolution. De nouvelles versions de la zone racine sont généralement publiées deux fois par jour. Le résolveur 1.1.1.1 dispose d'une application WebAssembly nommée « static_zone » et exécutée en parallèle de la logique DNS principale. C'est cette application qui transmet les nouvelles versions lorsqu'elles sont disponibles.
Que s'est-il passé ?
Le 21 septembre, dans le cadre d'une modification connue et planifiée de la gestion de la zone racine, un nouveau type d'enregistrement de ressource a été inclus dans les zones racines pour la première fois. Baptisé ZONEMD, ce nouvel enregistrement de ressource constitue, dans les faits, une somme de contrôle pour le contenu de la zone racine.
Cette zone est récupérée à l'aide d'un logiciel exécuté au sein du réseau central de Cloudflare. Elle est ensuite redistribuée vers les datacenters Cloudflare partout dans le monde. Après la modification, la zone racine contenant l'enregistrement ZONEMD a continué à être récupéré et distribué comme à la normale. Toutefois, les systèmes du résolveur 1.1.1.1 qui utilisent ces données ont éprouvé des difficultés pour analyser l'enregistrement ZONEMD record. Comme les zones doivent être chargées et transmises dans leur intégralité, l'échec de l'analyse de ZONEMD impliquait que la zone racine n'était pas utilisée dans les systèmes de résolution de Cloudflare. Certains des serveurs hébergeant l'infrastructure du résolveur de Cloudflare ne parvenaient pas à interroger les serveurs DNS racines directement, requête par requête, car ils n'avaient pas reçu la nouvelle zone racine. D'autres, toutefois, continuaient à se reposer sur la version fonctionnelle connue de cette dernière, toujours disponible dans leur mémoire cache, c'est-à-dire la version extraite le 21 septembre, avant la modification.
Le 4 octobre 2023, à 7 h UTC, les signatures DNSSEC de la version de la zone racine datant du 21 septembre ont expiré. Comme il n'existait aucune nouvelle version de cette zone que les systèmes de résolution de Cloudflare pouvaient utiliser, certains de ces derniers ont commencé à ne plus être en mesure de valider les signatures DNSSEC et ont par conséquent commencé à envoyer des messages d'erreur en guise de réponse (SERVFAIL). Le taux de génération de réponses SERVFAIL par les résolveurs de Cloudflare a augmenté de 12 %. Les schémas ci-dessous illustrent la progression de l'erreur et la manière dont elle est devenue visible pour les utilisateurs.
Chronologie et répercussions de l'incident
21 septembre 6 h 30 UTC : dernière extraction réussie de la zone racine.
4 octobre 7 h UTC : expiration des signatures DNSSEC contenues dans la zone racine obtenue le 21 septembre, avec pour résultat une augmentation des réponses SERVFAIL aux requêtes des clients.
7 h 57 : arrivée des premiers signalements externes de réponses SERVFAIL inattendues.
8 h 03 : déclaration de l'incident en interne chez Cloudflare.
8 h 50 : tentative initiale visant à empêcher le résolveur 1.1.1.1 d'émettre des réponses basées sur le fichier de zone racine obsolète à l'aide d'une règle de forçage.
10 h 30 : déploiement d'une mesure empêchant le résolveur 1.1.1.1 de précharger le fichier de zone racine dans son intégralité.
10 h 32 : retour à la normale des réponses.
11 h 02 : fin de l'incident.
Le graphique ci-dessous montre la frise chronologique des répercussions par rapport au pourcentage de requêtes DNS ayant reçu une erreur SERVFAIL en réponse :
Nous nous attendons à un certain volume de base d'erreurs SERVFAIL pour le trafic normal, en période d'activité normale. Ce pourcentage se situe généralement autour des 3 %. Ces erreurs SERVFAIL peuvent résulter de problèmes légitimes au sein de la chaîne DNSSEC, d'échecs de la connexion aux serveurs de référence, d'un délai de réponse trop long de la part des serveurs de référence et de bien d'autres sources. Au cours de l'incident, la quantité d'erreurs SERVFAIL s'est élevée à 15 % du total des requêtes. L'impact n'était toutefois pas distribué de manière homogène à travers le monde et se concentrait principalement dans nos plus grands datacenters, comme ceux d'Ashburn, en Virginia, de Francfort, en Allemagne, et de Singapour.
Les raisons à l'origine de l'incident
Pourquoi l'analyse de l'enregistrement ZONEMD a échoué
Le DNS utilise un format binaire pour stocker les enregistrements de ressources. Sous ce format binaire, le type de l'enregistrement de ressource (TYPE) est stocké sous la forme d'un nombre entier à 16 bits. Le type d'enregistrement de ressource détermine la manière dont les données de la ressource (RDATA) sont analysées. Un type d'enregistrement défini sur 1 signifie qu'il s'agit d'un enregistrement A et que les RDATA peuvent être considérées comme une adresse IPv4. En réciproque, le type 28 désigne un enregistrement AAAA, dont les RDATA peuvent être analysées sous la forme d'une adresse IPv6. Un analyseur qui rencontre un type d'enregistrement inconnu ne saura pas comment analyser ses RDATA, mais n'aura heureusement pas à le faire : le champ RDLENGTH indique la longueur du champ RDATA, soit un paramètre qui permet à l'analyseur de traiter l'enregistrement comme un élément de données opaque.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
L'application static_zone n'a pas pris en charge le nouvel enregistrement ZONEMD, car jusqu'ici, nous avions choisi de distribuer la zone racine en interne sous son format de présentation, plutôt que sous son format binaire. Lorsque nous observons la représentation texte de quelques enregistrements de ressource, nous pouvons constater la présence de bien plus de variations dans la manière dont les différents enregistrements sont présentés.
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023100400 1800 900 604800 86400
. 86400 IN RRSIG SOA 8 0 86400 20231017050000 20231004040000 46780 . J5lVTygIkJHDBt6HHm1QLx7S0EItynbBijgNlcKs/W8FIkPBfCQmw5BsUTZAPVxKj7r2iNLRddwRcM/1sL49jV9Jtctn8OLLc9wtouBmg3LH94M0utW86dKSGEKtzGzWbi5hjVBlkroB8XVQxBphAUqGxNDxdE6AIAvh/eSSb3uSQrarxLnKWvHIHm5PORIOftkIRZ2kcA7Qtou9NqPCSE8fOM5EdXxussKChGthmN5AR5S2EruXIGGRd1vvEYBrRPv55BAWKKRERkaXhgAp7VikYzXesiRLdqVlTQd+fwy2tm/MTw+v3Un48wXPg1lRPlQXmQsuBwqg74Ts5r8w8w==
. 518400 IN NS a.root-servers.net.
. 86400 IN ZONEMD 2023100400 1 241 E375B158DAEE6141E1F784FDB66620CC4412EDE47C8892B975C90C6A102E97443678CCA4115E27195B468E33ABD9F78C
Lorsque nous rencontrons un enregistrement de ressource inconnu, il n'est pas toujours évident de savoir comment le traiter. De ce fait, la bibliothèque que nous utilisons pour analyser la zone racine en périphérie de notre réseau ne s'y risque même pas et renvoie à la place une erreur d'analyse.
Pourquoi une version obsolète de la zone racine a été utilisée
L'application static_zone, chargée de charger et d'analyser la zone racine afin de diffuser cette dernière localement (RFC 7706), stocke la dernière version en mémoire. Lorsqu'une nouvelle version est publiée et qu'elle l'analyse (et qu'elle y parvient !), l'application abandonne l'ancienne version. Toutefois, comme l'analyse a échoué, l'application static_zone n'est jamais passée à la nouvelle version et a continué d'utiliser l'ancienne indéfiniment. Quand le service 1.1.1.1 est lancé pour la première fois, l'application static_zone ne dispose pas d'une version existante en mémoire. Lorsque l'application tente d'analyser la zone racine, mais qu'elle n'y parvient pas, elle se rabat sur l'interrogation directe des serveurs racines concernant les requêtes entrantes, car elle ne dispose pas d'une version plus ancienne de la zone racine sur laquelle se replier.
Pourquoi la tentative initiale de désactiver static_zone n'a pas fonctionné
Au départ, nous avons tenté de désactiver l'application static_zone par le biais d'une règle de forçage, un mécanisme qui nous permet de modifier certains comportements du résolveur 1.1.1.1 de manière programmatique. La règle que nous avons déployée était la suivante :
phase = pre-cache set-tag rec_disable_static
Cette règle ajoute à chaque requête entrante la balise rec_disable_static. Nous vérifions la présence de cette balise au sein de l'application static_zone et, si nous la voyons apparaître, nous ne renvoyons pas de réponse de la zone racine statique, mise en cache. Toutefois, afin d'améliorer les performances du cache, les requêtes sont parfois transférées à un autre nœud, si le nœud actuel ne parvient pas à trouver la réponse dans son propre cache. Malheureusement, la balise rec_disable_static n'est pas incluse dans les requêtes transférées aux autres nœuds. C'est ce qui a amené l'application static_zone à continuer à répondre par des informations obsolètes, jusqu'à ce que nous désactivions totalement l'application.
Pourquoi les impacts ont été partiels
Cloudflare procède régulièrement au redémarrage alterné des serveurs qui hébergent nos services pour des tâches telles que la mise à jour du noyau, qui ne peut prendre effet qu'après un redémarrage complet du système. Au moment de la défaillance, les instances serveur du résolveur qui avaient été redémarrées entre la modification ZONEMD et l'invalidation des DNSSEC n'ont pas contribué à l'impact. Si elles avaient redémarré au cours de cette période de deux semaines, elles n'auraient pas pu charger la zone racine au démarrage et s'en seraient remises à la résolution par envoi de requêtes DNS aux serveurs racines à la place. En outre, le résolveur utilise une technique nommée « Diffuser du contenu obsolète » (RFC 8767) dans le but de pouvoir continuer à diffuser des enregistrements populaires depuis un cache potentiellement obsolète afin de limiter les impacts. Un enregistrement est considéré comme obsolète lorsqu'un nombre de secondes égal au TTL s'est écoulé depuis que l'enregistrement a été récupéré en amont. Cette fonctionnalité a évité une défaillance totale. Les impacts se sont fait principalement sentir dans nos plus grands datacenters, qui disposaient de nombreux serveurs n'ayant pas redémarré le service 1.1.1.1 au cours de cette période.
Mesures de correction et de suivi
Cet incident a eu des répercussions très étendues. En outre, nous prenons la disponibilité de nos services très au sérieux. Nous avons identifié plusieurs domaines d'amélioration et continuerons à nous efforcer de dénicher d'éventuelles autres lacunes susceptibles d'entraîner une récidive.
Dans l'immédiat, nous travaillons sur ce qui suit :
Visibilité : nous allons ajouter des alertes conçues pour nous informer lorsque l'application static_zone diffuse un fichier de zone racine obsolète. En effet, cette diffusion n'aurait pas dû passer inaperçue aussi longtemps. Si nous avions mieux surveillé la zone racine (et grâce aux possibilités de mise en cache existantes), la défaillance n'aurait eu aucun impact. Notre objectif consiste à protéger nos clients et leurs utilisateurs des modifications en amont.
Résilience : nous allons réévaluer la manière dont nous ingérons et distribuons la zone racine en interne. Nos pipelines d'ingestion et de distribution doivent pouvoir traiter les RRTYPE sans accroc et les éventuelles interruptions brèves du pipeline doivent être invisibles pour les utilisateurs finaux.
Tests : malgré la présence de tests en place autour de ce problème, y compris de tests liés à des modifications non publiées pour l'analyse des nouveaux enregistrements ZONEMD, nous n'avons pas suffisamment testé ce qui se produit lorsque l'analyse de la zone racine échoue. Nous allons améliorer notre couverture de tests, de même que les processus connexes.
Architecture : nous ne devrions pas utiliser de copies obsolètes de la zone racine passé un certain point. S'il est certes possible de continuer à utiliser des données de zone racine pendant une période limitée, ces dernières entraînent des risques opérationnels inacceptables après un moment. Nous allons prendre des mesures pour nous assurer que la durée de vie des données de zone racine mises en cache soit mieux gérée, comme décrit dans la RFC 8806 : Running a Root Server Local to a Resolver (Exécuter un serveur racine en local pour un résolveur).
Conclusion
Nous sommes profondément désolés que cet incident se soit produit. Nous en retirons un message clair : il ne fait jamais supposer que rien ne va changer ! De nombreux systèmes modernes sont bâtis autour d'une longue chaîne de bibliothèques extraites au sein de l'exécutable final et chacune d'elles peut comporter des bugs ou ne pas être mise à jour suffisamment tôt pour que les programmes puissent fonctionner correctement lorsque des changements se produisent au niveau des intrants. Nous comprenons l'importance du fait de disposer d'une bonne structure de tests en place, capable de détecter les régressions, de même que les systèmes et les composants qui rencontrent des défaillances invisibles au premier abord après une modification des intrants. Nous savons que nous devons toujours partir du principe que les changements de « format » au niveau des systèmes les plus essentiels d'Internet (le DNS et le BGP) auront forcément des répercussions.
Nous avons beaucoup de suivi à effectuer en interne et travaillons sans relâche pour nous assurer que ce genre d'incident ne se reproduise plus jamais.