Le DDoS de Spamhaus en 2013 a fait de la récursion DNS ouverte un

Résumé

Entre le 18 et le 27 mars 2013, Cloudflare a observé plusieurs phases d’une campagne visant Spamhaus puis des infrastructures situées sur les chemins de mitigation et d’interconnexion ; cette chronologie délimitée ne décrit pas une panne générale d’Internet. [1][2]
Les débits d’environ 10, 75 à 90, 120 et 300 Gbit/s, ainsi que le nombre supérieur à 30 000 résolveurs, sont des observations attribuées à Cloudflare depuis des points de mesure différents, et non des mesures universelles du réseau mondial. [1][2]
Le chemin exécutable associait une adresse source usurpée, un résolveur récursif accessible à des clients non autorisés, une réponse amplifiée et des liens partagés conduisant vers la victime ou son prestataire de protection. [4][10]
Un résolveur récursif et un serveur DNS faisant autorité remplissent des fonctions distinctes : fermer une récursion indésirable ne signifie pas retirer du réseau les serveurs faisant autorité nécessaires à la publication des zones.
La RFC 5358 et les BCP 38 et 84 avaient déjà documenté, avant l’incident, deux contrôles séparés : limiter la récursion aux clients prévus et empêcher l’émission de paquets portant des adresses source impossibles. [4][5][6]
L’interruption du site web et de certains réseaux de soutien n’établit pas que les données distribuées des listes de blocage de Spamhaus aient cessé d’être disponibles dans le monde ; la disponibilité doit être qualifiée par service, chemin et période d’observation. [3]
Les RFC ultérieures, les travaux de RIPE, MANRS, DNS-OARC et la recherche offrent des moyens modernes de comparaison et de vérification, mais ne prouvent pas que tous ces mécanismes existaient ou étaient déployables sous une forme identique en mars 2013. [7][8][9][14][15][16][17][18][19]
Le véritable test de responsabilité consiste à fermer la récursion non voulue, valider les adresses source, documenter les décisions d’anycast et de routage, conserver les preuves de coordination et démontrer depuis l’extérieur que la réparation fonctionne durablement.

Un incident d’infrastructure, pas une légende de volume

La campagne qui a visé Spamhaus en mars 2013 est souvent ramenée à une formule spectaculaire et à un chiffre de débit. Cette présentation masque pourtant ce que l’incident permet réellement d’étudier : une chaîne de décisions techniques réparties entre des opérateurs qui ne dépendaient pas tous les uns des autres. L’attaque n’avait pas besoin qu’un seul réseau commette une faute décisive. Elle exploitait la combinaison de nombreuses récursions DNS accessibles, de réseaux laissant sortir des paquets usurpés, de réponses plus volumineuses que les requêtes et de chemins d’interconnexion sur lesquels ces réponses convergeaient.

La période pertinente s’étend du 18 au 27 mars 2013. Les récits contemporains de Cloudflare décrivent d’abord une attaque ayant saturé la connexion utilisée par Spamhaus et rendu son site web inaccessible. Ils relatent ensuite des vagues réfléchies plus importantes, puis un déplacement de la pression vers des infrastructures utilisées par le prestataire de mitigation, ses fournisseurs et ses interconnexions. Ces phases appartiennent à une même campagne, mais elles ne doivent pas être fondues dans une mesure unique et continue.

Une observation réalisée près du client protégé, une autre au sein d’un réseau anycast et une troisième sur une liaison avec un fournisseur ne décrivent ni le même emplacement ni nécessairement le même domaine de défaillance. [1][2]

L’expression selon laquelle l’attaque aurait « presque cassé Internet » relève de la mise en scène publique de l’événement, notamment dans le titre choisi à l’époque par Cloudflare. Elle ne constitue pas la conclusion d’une mesure mondiale synchronisée. Les sources retenues ne démontrent ni une panne globale, ni l’arrêt d’un point d’échange déterminé, ni une interruption universelle des services utilisant les données de Spamhaus. Elles montrent qu’une campagne de réflexion DNS a atteint des volumes importants aux points observés et qu’elle a fait peser une pression réelle sur des réseaux partagés.

C’est déjà un constat suffisamment grave ; il n’est pas nécessaire de l’agrandir au-delà des preuves. [2]

L’intérêt durable de l’incident tient donc moins au record annoncé qu’à la possibilité de suivre les paquets. Qui pouvait empêcher une requête portant une adresse source falsifiée de quitter son réseau ? Qui décidait quels clients avaient le droit d’utiliser un résolveur récursif ? Qui choisissait les routes, les annonces anycast, les capacités de nettoyage et les accords de transit ? Qui pouvait distinguer l’indisponibilité du site web de celle des données distribuées ? La responsabilité devient intelligible lorsque ces questions sont rattachées au fonctionnement observable des systèmes.

Une chronologie bornée du 18 au 27 mars

Selon le premier compte rendu de Cloudflare, Spamhaus a sollicité une protection après qu’un trafic d’environ 10 Gbit/s eut saturé sa connexion. Le site web était alors devenu inaccessible. Cloudflare a ensuite décrit des vagues de l’ordre de 75 à 90 Gbit/s, largement alimentées par la réflexion sur des résolveurs DNS récursifs ouverts. Ces nombres caractérisent ce que le prestataire disait voir dans son environnement de mitigation ; ils ne représentent pas une série métrologique indépendante couvrant tous les réseaux traversés. [1]

Le second compte rendu relate une escalade vers environ 120 Gbit/s et un changement de cible opérationnelle. Une partie de la pression ne se concentrait plus uniquement sur l’adresse du client protégé : elle affectait les fournisseurs et des liaisons tournées vers l’interconnexion. Le chiffre de 300 Gbit/s, devenu l’emblème médiatique de l’événement, appartient à ce récit côté fournisseur. Il doit rester attaché à cet observateur et à ce contexte. Une valeur mesurée ou estimée sur un chemin de mitigation n’est pas, par simple répétition, transformée en débit de l’ensemble d’Internet. [2]

Cette distinction a une conséquence importante pour l’analyse des pannes. Lorsqu’un lien proche du client est saturé, l’application peut devenir inaccessible même si le reste du réseau conserve de la capacité. Lorsqu’un système anycast répartit le trafic, la charge peut se déplacer entre plusieurs sites. Lorsqu’un assaillant vise ensuite des adresses ou des chemins utilisés par les fournisseurs, la limite de capacité peut apparaître ailleurs. Parler d’un seul pic sans préciser le point d’observation efface ces déplacements et donne l’illusion qu’une grandeur unique décrit toute la campagne.

La chronologie ne permet pas davantage d’attribuer une panne précise à un point d’échange particulier. Le fait que des liaisons tournées vers le peering aient transporté ou subi du trafic ne suffit pas à établir l’arrêt d’une infrastructure déterminée. Il faudrait pour cela des mesures liées à ses ports, à sa matrice de commutation, à ses périodes d’incident et à ses communications opérationnelles. Les sources disponibles justifient une formulation plus prudente : la campagne a atteint des surfaces de fournisseurs et d’interconnexion, où elle pouvait imposer des coûts à des réseaux étrangers au différend initial. [2][16]

La date de clôture du 27 mars fixe également une limite intellectuelle. Des arrestations, analyses et normes postérieures peuvent éclairer certains aspects, mais elles ne doivent pas être introduites rétroactivement comme si elles décrivaient exactement ce que chaque acteur savait pendant ces dix jours. Le dossier technique est assez solide pour expliquer la réflexion DNS et les contrôles pertinents. Il est beaucoup moins complet sur l’identité de chaque participant, sa connaissance préalable, les effets subis par tous les tiers et le partage causal de la charge.

Ce que Cloudflare a observé — et ce que ces chiffres ne prouvent pas

Une mesure de trafic n’a de sens qu’avec un observateur, une interface, une méthode et une fenêtre temporelle. Les valeurs d’environ 10 Gbit/s puis de 75 à 90 Gbit/s proviennent du récit de Cloudflare consacré à la protection initiale du client. Le mouvement vers 120 Gbit/s et la valeur de 300 Gbit/s apparaissent dans le compte rendu consacré à l’escalade vers les réseaux de fournisseurs. Les quatre nombres doivent donc être cités comme des observations de Cloudflare, non comme une mesure universelle obtenue par consensus entre opérateurs. [1][2]

La même règle vaut pour les plus de 30 000 résolveurs mentionnés. Cloudflare a décrit un ensemble très important de serveurs récursifs participant aux réponses qu’il observait. Ce nombre permet d’expliquer le caractère distribué de l’amplification. Il ne constitue toutefois ni un recensement de tous les résolveurs ouverts d’Internet, ni une liste complète des systèmes autonomes concernés, ni la preuve que chaque opérateur connaissait l’exposition de son équipement. Une adresse répondante peut être inventoriée ; la connaissance interne, la propriété administrative et l’historique d’une configuration demandent d’autres éléments.

L’estimation d’une amplification proche d’un facteur cent se rapporte elle aussi à la forme de requête et de réponse décrite par Cloudflare. Le rapport entre la petite requête émise et la réponse retournée aide à comprendre comment un débit relativement faible à la source pouvait produire un débit entrant beaucoup plus élevé. Il ne faut pas en faire une constante du protocole DNS. La taille dépend du nom demandé, du type de données, des extensions employées, de la mise en cache, de la fragmentation, du comportement du serveur et de la manière dont le trafic est compté. [1][11]

Une évaluation robuste distinguerait au moins le débit des requêtes falsifiées, le débit total des réponses émises par les réflecteurs, le trafic reçu à chaque site de mitigation, les pertes avant ce site, la capacité des liens de transit et la charge vue sur les interfaces proches de l’application. Sans mesures coordonnées sur ces plans, le maximum relevé en un endroit ne révèle pas tout ce qui s’est passé ailleurs. Inversement, l’absence de mesure publique sur un chemin ne signifie pas qu’il n’a subi aucun effet ; elle signifie seulement que cet effet reste non quantifié.

Cette discipline protège l’analyse contre deux erreurs opposées. La première consiste à universaliser les chiffres du fournisseur jusqu’à prétendre qu’Internet entier était sur le point de s’arrêter. La seconde consiste à minimiser l’événement au motif qu’aucune mesure globale n’existe. Les observations attribuées montrent bel et bien une attaque distribuée de grande ampleur, capable de déplacer la pression au-delà du client initial. Leur portée doit simplement rester celle des points depuis lesquels elles ont été produites.

Le chemin exécutable de la réflexion DNS

Le mécanisme commençait par une fausse information dans l’en-tête IP. Un système envoyait une petite requête DNS en UDP tout en inscrivant comme adresse source celle de la victime ou d’une infrastructure située sur son chemin de protection. Comme UDP n’établit pas au préalable une connexion garantissant l’identité du demandeur, le serveur destinataire répondait à l’adresse indiquée. La requête était envoyée par l’assaillant ; la réponse, elle, était émise par un tiers qui croyait s’adresser au client déclaré.

Le tiers décisif était un résolveur récursif accessible depuis des réseaux auxquels il n’aurait pas dû nécessairement offrir ce service. Un tel résolveur reçoit une question, recherche les données nécessaires dans la hiérarchie DNS lorsqu’elles ne se trouvent pas déjà dans son cache, puis renvoie le résultat au client apparent. Cloudflare a indiqué que les requêtes observées portaient notamment sur des données relatives à ripe.net. Les réponses, plus volumineuses que les déclencheurs, convergeaient vers l’adresse usurpée. La répétition du procédé auprès de dizaines de milliers de résolveurs transformait de faibles émissions distribuées en une charge considérable au point de convergence. [1][2]

Le chemin comprenait ainsi plusieurs décisions indépendantes. Le réseau d’origine décidait, par sa configuration, si un paquet portant une adresse source impossible pouvait sortir. Le résolveur décidait, par ses interfaces et ses règles d’accès, s’il acceptait une récursion demandée par un client arbitraire. Les routeurs BGP sélectionnaient ensuite des chemins vers l’adresse annoncée. Les accords de peering et de transit déterminaient les liaisons disponibles. Le fournisseur de mitigation décidait des annonces anycast, du filtrage, du nettoyage et des éventuels changements de route.

Enfin, la capacité de la liaison la plus contrainte déterminait souvent si l’application pouvait encore être jointe.

Une réponse réfléchie ne révèle pas directement l’identité du système ayant forgé la requête. Elle montre qu’un paquet de réponse a été généré et acheminé vers l’adresse usurpée. Les journaux du résolveur peuvent conserver l’adresse falsifiée, pas nécessairement l’origine réelle. Des données de flux et des enregistrements aux frontières du réseau source seraient nécessaires pour remonter davantage le chemin. Même alors, les machines compromises, les relais et les modalités de commande peuvent compliquer l’attribution.

Cette séparation est essentielle sur le plan juridique comme sur le plan opérationnel. Le fait qu’un serveur ait participé comme réflecteur ne prouve ni que son opérateur connaissait l’attaque, ni qu’il l’approuvait, ni qu’il en soit juridiquement responsable. Il prouve une capacité technique exploitable : le service acceptait une demande externe et produisait une réponse vers une adresse qui pouvait être usurpée. La question de responsabilité éditoriale doit partir de ce contrôle observable, puis s’arrêter là où les preuves sur la connaissance, l’intention ou le droit font défaut.

Résolution récursive et DNS faisant autorité

Le DNS ne forme pas une catégorie opérationnelle uniforme. Un serveur faisant autorité publie les données des zones dont il a la charge. Il répond afin que les autres systèmes puissent connaître les adresses, délégations et informations associées à ces zones. Sa présence publique est normalement nécessaire : s’il n’était joignable que par un petit cercle de clients, la résolution générale des noms qu’il sert ne fonctionnerait plus.

Un résolveur récursif remplit une autre tâche. Il agit pour le compte d’un client, parcourt la hiérarchie DNS si nécessaire, met certaines réponses en cache et retourne un résultat consolidé. Il peut être destiné aux employés d’une entreprise, aux abonnés d’un fournisseur d’accès ou aux machines d’un réseau précis. Lorsqu’il accepte les demandes récursives de n’importe quelle adresse d’Internet, il offre à des inconnus une capacité qui peut être détournée pour la réflexion. La description fondamentale du fonctionnement DNS aide à maintenir cette distinction entre publication faisant autorité et résolution pour le compte d’un client. [10]

Un même logiciel ou un même hôte peut techniquement exercer les deux fonctions. Cela n’annule pas leur différence. L’opérateur doit savoir sur quelles interfaces la récursion est active, quels réseaux sont autorisés, quelles vues et listes de contrôle s’appliquent, et comment la partie faisant autorité reste publique sans ouvrir la partie récursive. Dire qu’une machine « est un serveur DNS » ne suffit donc ni pour établir le défaut ni pour définir la réparation.

Fermer un résolveur ouvert ne consiste pas à retirer les zones publiques ni à interrompre le service faisant autorité. Il s’agit de restreindre la récursion aux clients prévus, de séparer les rôles lorsque cela facilite le contrôle et de tester le résultat depuis un réseau extérieur non autorisé. Une configuration peut paraître correcte sur son interface principale tout en restant exposée sur IPv6, sur une adresse secondaire, après un basculement ou par l’intermédiaire d’un équipement oublié. L’inventaire et la vérification externe comptent autant que l’intention déclarée.

Les serveurs faisant autorité peuvent eux aussi être concernés par d’autres formes d’abus et par la nécessité de limiter certaines réponses. Les normes ultérieures sur les réponses ANY, les architectures faisant autorité de grande taille et d’autres mécanismes de défense sont pertinentes pour une assurance moderne. Elles ne changent cependant pas la nature précise de la chaîne observée en 2013 : l’un des défauts centraux était une récursion accessible à des demandeurs arbitraires, combinée à la possibilité d’usurper une adresse source. [8][9]

Cette précision évite une politique de sécurité contre-productive. Une injonction vague à « fermer les DNS » pourrait dégrader la disponibilité des zones sans éliminer la récursion indésirable. Une réparation vérifiable nomme le rôle, l’interface, la population autorisée, le comportement attendu et le test négatif effectué depuis l’extérieur.

La récursion comme contrôle direct de l’opérateur

La RFC 5358, publiée en 2008, avait décrit le recours aux serveurs récursifs comme réflecteurs plusieurs années avant la campagne contre Spamhaus. Son allocation des contrôles est claire : l’opérateur d’un résolveur doit limiter la récursion aux clients auxquels le service est destiné, tandis que les opérateurs de réseau doivent empêcher la propagation de paquets portant des adresses source falsifiées. Le problème n’a donc pas été inventé après l’incident pour imposer une norme rétrospective. Une mesure fondamentale était déjà documentée avant mars 2013. [4]

Le contrôle de la récursion appartient à l’opérateur qui choisit le logiciel, les interfaces d’écoute, les listes de clients, les règles du pare-feu, les vues DNS, les paramètres de cache et les fonctions activées. Cet opérateur est le mieux placé pour savoir si le service doit répondre seulement à un réseau interne, à des abonnés déterminés ou à d’autres populations autorisées. Lorsqu’un équipement combine résolution récursive et publication faisant autorité, il lui revient également de préserver la distinction dans la configuration.

L’absence d’intention hostile n’efface pas ce contrôle. Un résolveur ouvert peut n’émettre individuellement qu’un volume modeste et son opérateur peut ne jamais avoir entendu parler de Spamhaus. Il n’en demeure pas moins qu’une configuration locale a fourni une capacité exécutable à un demandeur non authentifié. La responsabilité technique consiste alors à supprimer cette capacité, à en examiner les causes et à démontrer qu’elle ne réapparaît pas après redémarrage, mise à jour ou basculement.

La preuve attendue devrait comprendre un inventaire daté des adresses et interfaces, la configuration des plages autorisées, des tests externes depuis plusieurs réseaux, l’identification des exceptions et une vérification après correction. Les journaux ou données de flux peuvent montrer quelles requêtes non sollicitées ont été reçues et quelles tailles de réponse ont été produites. Les dispositifs de limitation de débit peuvent réduire l’impact, mais ils ne remplacent pas une frontière d’accès correcte. Un service récursif qui reste inutilement ouvert demeure une capacité disponible, même s’il répond moins vite.

Les techniques ultérieures, comme certains échanges protégés par DNS Cookies, peuvent rendre l’usurpation plus difficile lorsque les deux extrémités les prennent en charge. Elles constituent une défense supplémentaire, pas une justification pour conserver une récursion sans restriction. [7] De même, réduire les réponses à certaines requêtes diminue un vecteur d’amplification, mais ne décide pas qui a le droit de demander au résolveur d’agir en son nom.

La limite de cette responsabilité doit rester visible. Le résolveur voit l’adresse source inscrite dans le paquet ; il ne contrôle pas le réseau éloigné qui a laissé fabriquer cette adresse. Fermer la récursion traite le réflecteur. Cela ne remplace pas la validation à la source. Si une organisation exploite à la fois le réseau d’accès et le résolveur, elle porte les deux obligations, mais chacune possède ses propres tests et ses propres preuves.

L’usurpation et la validation à la frontière du réseau

La réflexion ne fonctionne vers une victime choisie que si l’émetteur peut faire accepter une adresse source qui ne lui appartient pas. Le BCP 38, publié sous la forme de la RFC 2827, situe le contrôle le plus efficace près de l’origine : à l’interface où un fournisseur connaît les préfixes légitimes de son client ou de son segment interne. Un paquet arrivant de ce client avec une adresse qui ne peut pas raisonnablement provenir de lui devrait être rejeté avant d’entrer dans le reste d’Internet. [5]

Le terme « filtrage entrant » est parfois source de confusion. Il décrit le paquet tel qu’il entre chez le fournisseur depuis le client, mais le bénéfice collectif est celui d’un contrôle de sortie : le trafic falsifié ne quitte pas le domaine d’origine. Le client contrôle les machines et les configurations qui génèrent ses paquets. Le fournisseur d’accès contrôle la politique appliquée à la frontière client. Ces responsabilités sont complémentaires sans être identiques.

Les réseaux multihomés rendent l’application plus délicate. Un trafic légitime peut emprunter un chemin de sortie différent de celui que suggérerait une vérification stricte du chemin inverse. Le BCP 84 ne transforme pas cette difficulté en permission d’abandonner la validation. Il décrit des approches adaptées aux topologies complexes, notamment des listes explicites et plusieurs formes de vérification du chemin, afin de rejeter les sources impossibles sans bloquer les asymétries légitimes. [6]

La preuve doit porter sur l’interface réelle, pas seulement sur une politique générale. Il faut connaître les préfixes autorisés pour chaque client, le mécanisme de validation, les exceptions accordées, les compteurs de rejet et les résultats de tests contrôlés. Une exception créée pour un réseau multihomé doit avoir un propriétaire, une justification, une durée et un contrôle compensatoire. Après une modification BGP, une acquisition ou un nouveau lien, la politique doit être retestée, car la relation entre interface et préfixe peut avoir changé.

Un opérateur de transit n’est pas automatiquement responsable de tout paquet usurpé qu’il transporte. Sa capacité à distinguer le vrai du faux est la plus forte aux frontières où il connaît la relation entre le client et ses ressources d’adressage. Plus loin sur un chemin de transit arbitraire, cette connaissance peut être absente ou incomplète. L’attribution doit donc identifier la frontière précise à laquelle un contrôle était possible, et non distribuer la faute à tous les réseaux apparaissant sur une route plausible.

Les difficultés persistantes de déploiement de la validation des adresses source, documentées bien après 2013, ne réduisent pas son importance. Elles montrent au contraire pourquoi une affirmation abstraite de conformité est insuffisante. [15] Un réseau responsable doit être capable de démontrer quelles populations ont été testées, quels paquets invalides ont été bloqués et quelles zones restent hors couverture.

L’amplification transforme une négligence locale en coût collectif

À l’échelle d’un seul équipement, une récursion ouverte peut sembler mineure. Quelques réponses par seconde ne saturent ni le serveur ni sa connexion. De la même manière, un réseau d’accès peut ne voir qu’un mince flux de requêtes usurpées réparties entre de nombreux clients. La réflexion modifie toutefois l’unité pertinente : ce n’est plus la contribution isolée qu’il faut regarder, mais la convergence de milliers de contributions sur un même lien.

Le demandeur envoie un petit déclencheur ; le résolveur produit une réponse plus grande ; la victime reçoit la somme des réponses. Cloudflare a indiqué avoir observé plus de 30 000 résolveurs et un rapport d’amplification proche de cent pour la forme de trafic décrite. Ces chiffres ne sont pas des constantes universelles, mais ils illustrent le mécanisme d’agrégation. [1] Aucun réflecteur n’a besoin d’être indispensable. La campagne conserve sa puissance tant qu’une population importante reste disponible.

Cette structure crée une externalité de réseau. L’opérateur qui laisse une récursion ouverte évite le coût d’un inventaire ou d’une correction, tandis que la congestion est supportée par une organisation distante. Le réseau qui ne valide pas les sources peut bénéficier d’une exploitation plus simple, tandis que les réponses amplifiées frappent une victime, un prestataire de mitigation, un fournisseur de transit ou une liaison partagée. Les coûts et les choix ne se trouvent pas au même endroit.

L’anycast et les capacités de nettoyage peuvent absorber une partie du choc, mais ils ne suppriment pas l’externalité. Ils déplacent et répartissent le trafic selon les annonces et la sélection BGP. Une charge précédemment concentrée sur la connexion de Spamhaus peut alors se répartir entre plusieurs sites ou apparaître sur des interconnexions en amont. Si un site dispose d’une grande capacité interne mais dépend d’un lien de peering plus étroit, ce lien devient la limite utile. [2]

La faiblesse de chaque contribution interdit une responsabilité fondée exclusivement sur le volume individuel. Un résolveur qui n’a produit qu’une fraction du total pouvait néanmoins être configuré de manière exploitable. Un réseau ayant laissé passer peu de requêtes usurpées contrôlait tout de même une condition nécessaire. La bonne question n’est pas de savoir si le retrait d’un seul participant aurait arrêté la campagne. Elle est de savoir si chaque opérateur pouvait supprimer, dans son propre domaine, une capacité dont la répétition à grande échelle rendait l’attaque possible.

C’est pourquoi les dénominateurs comptent. Annoncer que cent résolveurs ont été corrigés ne dit rien si l’organisation en exploite dix mille sans les avoir inventoriés. Indiquer qu’un certain nombre de paquets ont été bloqués ne prouve pas que toutes les frontières clients appliquent la validation. Une responsabilité vérifiable demande la population totale, la couverture des tests, les exceptions, les échecs restants et la date de la dernière observation.

Anycast, BGP, peering et transit : le déplacement du point de rupture

L’anycast permet à plusieurs sites d’annoncer la même destination afin que le routage conduise généralement le trafic vers un emplacement sélectionné par la politique BGP. Dans une situation de DDoS, cette architecture peut répartir une charge qui aurait sinon convergé vers un seul centre. Elle offre aussi des possibilités de filtrage et de nettoyage proches de différents points d’entrée. Cependant, elle ne crée pas une capacité uniforme et ne garantit pas que tous les chemins disposent de la même marge.

BGP ne choisit pas une route en fonction d’une connaissance globale de la congestion. Les politiques locales, les relations commerciales, la visibilité des annonces et les préférences de chemin influencent le site atteint. Deux réseaux sources peuvent donc envoyer des réponses réfléchies vers des sites différents. Un changement d’annonce peut déplacer la charge, parfois vers une région mieux équipée, parfois vers une interconnexion moins préparée. Pour comprendre une défaillance, il faut relier les volumes observés aux annonces actives, aux sites, aux ports et aux fournisseurs concernés.

Les comptes rendus de Cloudflare indiquent que la pression s’est étendue au-delà de l’adresse du client vers des surfaces de fournisseurs et d’interconnexion. [1][2] Cette évolution est importante sans justifier l’invention d’une panne d’échange. Le mot « peering » décrit une relation et un chemin possibles ; il ne démontre ni la saturation d’un commutateur précis ni l’indisponibilité générale des participants. Une affirmation plus forte demanderait des données provenant de l’infrastructure concernée.

Cloudflare contrôlait ses annonces anycast, ses choix de nettoyage, ses changements de route, sa capacité provisionnée et ses communications avec les pairs et les fournisseurs de transit. Il contrôlait également la précision de ses déclarations publiques sur les mesures. Les opérateurs de transit contrôlaient leurs interfaces, leurs politiques clients, leurs capacités et leur réponse à la congestion. Les points d’échange contrôlaient leur matrice partagée, leurs ports et leurs procédures d’incident. Aucun de ces rôles ne permet d’attribuer automatiquement le volume ou la faute d’un autre.

Les preuves utiles comprennent la liste des sites annonçant le préfixe, les routes vues avant et pendant l’incident, les changements de politique horodatés, les données de flux par interface, les pertes, les files d’attente, les limites de capacité et les échanges de coordination. Elles doivent distinguer le trafic accepté, rejeté, nettoyé et transmis. Sans ce contexte, un débit agrégé peut mélanger plusieurs sites et masquer le lien réellement contraint.

La continuité dépend donc d’une chaîne, pas d’une seule « grande capacité ». Une application protégée reste indisponible si le trafic légitime n’atteint pas le site de nettoyage, si une interconnexion sature en amont ou si le chemin de retour ne fonctionne pas. L’architecture doit être testée sous basculement, et pas seulement décrite dans un schéma. La réparation après incident doit montrer que les changements de routage et de capacité ont amélioré le comportement observé depuis plusieurs réseaux extérieurs.

Site web, réseaux de soutien et données DNSBL

Le premier effet visible relaté par Cloudflare était l’indisponibilité du site web de Spamhaus après saturation de sa connexion. [1] Les phases ultérieures ont touché des environnements de fournisseurs et des chemins soutenant la mitigation. Spamhaus a par ailleurs indiqué que son site, certains hôtes, des partenaires DNS et des services de soutien avaient été visés, tout en affirmant que ses données distribuées de lutte contre le spam étaient restées disponibles. [3]

Ces éléments ne sont pas contradictoires, car ils concernent des couches distinctes. Un site web fournit des pages, des explications, des contacts et des informations d’état. Une liste de blocage distribuée par DNS repose sur d’autres points de service, d’autres répliques, d’autres caches et d’autres chemins. La perte du portail web peut gêner l’assistance et la communication publique sans supprimer toutes les réponses que des systèmes de messagerie obtiennent auprès de l’infrastructure de données.

L’inverse est également vrai : la continuité déclarée des données distribuées ne rend pas négligeable l’interruption du site et des réseaux de soutien. Elle ne prouve pas non plus que chaque utilisateur, chaque région et chaque chemin ait connu une disponibilité parfaite. Les sources permettent une conclusion limitée : il n’est pas établi que le service mondial de filtrage ait cessé, et Spamhaus a déclaré que ses données distribuées continuaient d’être disponibles. Elles ne permettent pas de nier d’éventuelles dégradations locales non mesurées.

Une analyse de continuité devrait séparer l’accessibilité HTTP, la santé du DNS faisant autorité, la réussite des requêtes DNSBL, la fraîcheur des mises à jour, la latence, les erreurs et la disponibilité des systèmes de soutien. Chaque test devrait identifier son origine réseau, sa destination, sa période et le protocole observé. Un voyant global « opérationnel » ou « indisponible » est trop grossier pour rendre compte d’un service distribué.

Spamhaus contrôlait son architecture de service, ses mécanismes de réplication et la précision de ses communications sur la reprise. Il ne contrôlait pas les résolveurs ouverts éloignés ni les réseaux autorisant l’usurpation. Cloudflare contrôlait les chemins qu’il annonçait et le trafic qu’il acceptait pour la mitigation. Les partenaires DNS et les fournisseurs contrôlaient leurs propres composants. La continuité ne peut être attribuée correctement qu’en nommant le service et l’opérateur capables d’agir sur celui-ci.

Cette distinction protège aussi contre l’exagération de l’impact sur les tiers. Les données disponibles ne démontrent pas un arrêt mondial du filtrage des courriels. Elles ne quantifient pas non plus tout retard, toute perte ou toute congestion subie par des utilisateurs extérieurs. La formulation responsable conserve ces deux limites au lieu de transformer une panne web en disparition générale ou une continuité partielle en absence totale d’impact.

Répartir la responsabilité selon le contrôle pratique

La responsabilité réseau ne suit pas automatiquement le prestige, la taille ou le rôle institutionnel d’une organisation. Elle suit la capacité de modifier un élément réel du chemin. Dans cette campagne, plusieurs opérateurs détenaient des contrôles différents, et aucun récit sérieux ne peut les fusionner en une responsabilité collective indifférenciée.

L’opérateur du résolveur contrôlait l’exposition de la récursion, les clients autorisés, les interfaces, les réponses et les éventuelles limites de débit. Il devait pouvoir identifier le service, corriger l’accès et vérifier la fermeture. Le réseau d’accès ou le fournisseur situé à la frontière client contrôlait la validation des adresses source. Il devait empêcher les paquets portant des préfixes impossibles de sortir, tout en gérant correctement les cas de multihoming.

Cloudflare contrôlait son dispositif anycast, ses capacités de nettoyage, ses annonces BGP, ses changements de route, sa coordination avec les pairs et les transitaires, ainsi que la portée de ses mesures publiques. Cela ne signifie pas qu’il contrôlait la population mondiale des réflecteurs ou les réseaux d’origine. Ses affirmations doivent être évaluées comme celles d’un observateur et d’un opérateur placé à certains points du chemin.

Les fournisseurs de transit contrôlaient leurs interfaces clients, leurs politiques de filtrage, leurs capacités et leurs procédures de coordination. Leur présence sur un chemin possible ne prouve pas qu’ils pouvaient identifier l’origine réelle de chaque paquet après plusieurs domaines de transit. Les points d’échange contrôlaient leurs ports, leur infrastructure partagée et leur réponse opérationnelle. Ils ne devraient être associés à un volume ou à une panne qu’à partir de données propres à cette infrastructure.

Spamhaus contrôlait l’architecture de ses services, ses relations avec ses prestataires, ses procédures de reprise et la précision de ses messages publics. Il ne contrôlait ni les résolveurs ouverts à distance ni les réseaux laissant sortir des sources falsifiées. L’analyse n’a pas besoin de prendre position sur la légitimité de ses listes de blocage pour constater cette séparation technique.

La victime, le réflecteur, le réseau source, le fournisseur de mitigation et le transporteur peuvent tous se trouver dans la même histoire sans porter la même obligation. La responsabilité n’est pas une addition de reproches moraux. Elle est une table de correspondance entre un composant, son propriétaire opérationnel, le contrôle disponible, la preuve de son état et la réparation vérifiée.

Cette approche impose également une limite aux conclusions juridiques. Une capacité mal configurée n’établit pas à elle seule une faute légale, une intention, une connaissance préalable ou une part précise de causalité. Une annonce ultérieure concernant une arrestation apporte un contexte, mais ne résout pas toutes les questions d’attribution technique et de responsabilité juridique liées à chaque action de la campagne. [3] Lorsque le dossier ne contient pas l’adjudication nécessaire, l’identité et la responsabilité de l’assaillant doivent rester hors conclusion.

Une chaîne de preuves adaptée à chaque opérateur

Pour un résolveur, la preuve commence par un inventaire daté. Celui-ci devrait associer chaque adresse et interface à un propriétaire, un rôle, une version logicielle, une source de configuration et une population de clients autorisés. Des sondes placées sur des réseaux extérieurs devraient vérifier qu’elles n’obtiennent aucune récursion. Des tests internes devraient confirmer que les clients légitimes continuent d’être servis. IPv4, IPv6, UDP, TCP, adresses secondaires et interfaces de basculement doivent être couverts.

Une capture de configuration ne suffit pas si elle ne correspond pas au système en exécution. Il faut conserver les résultats de sondes, les horodatages, les emplacements de test, les changements approuvés et les vérifications après redémarrage. Une réparation crédible doit survivre au remplacement d’un équipement, au rechargement d’un service et au basculement vers un site de secours.

Pour la validation des adresses source, l’inventaire porte sur les frontières. Chaque segment d’accès, client, classe de locataire ou lien géré doit être associé aux préfixes légitimes et au mécanisme appliqué : liste de contrôle, vérification du chemin inverse, méthode tenant compte des chemins possibles ou équivalent. Des tests autorisés utilisant des sources invalides doivent établir si les paquets quittent effectivement la frontière. Les exceptions doivent être visibles et retestées après les changements de routage. [5][6]

La télémétrie doit relier les deux plans. Les données du résolveur peuvent indiquer les noms et types demandés, les tailles de réponse, les taux, la troncature et l’effet des limites, avec une conservation proportionnée à la nécessité opérationnelle. Les données de frontière peuvent indiquer les rejets de sources impossibles par interface. Les données de flux et de capacité montrent où les réponses réfléchies sont entrées, quel lien a subi une pression et quelles routes étaient actives.

Un avis d’abus exploitable devrait contenir une fenêtre en UTC, les adresses concernées, le protocole, des exemples de paquets, la méthode de mesure et un identifiant de dossier permettant la coordination. Une simple liste d’adresses sans contexte rend la reproduction difficile. À l’inverse, une collecte excessive de données n’est pas nécessaire : l’objectif est de prouver le comportement du service et la correction du contrôle, non d’accumuler des informations sans limite.

Les prestataires anycast devraient conserver les sites annonçant le service, les changements d’annonce, la distribution du trafic, les points de congestion et les échanges avec les fournisseurs. Les opérateurs de transit devraient pouvoir démontrer la politique de leurs frontières clients et les mesures prises lorsqu’un chemin sature. Les exploitants de services devraient distinguer les mesures de disponibilité par composant. Chacun doit produire les preuves correspondant au contrôle qu’il détient, pas celles d’un autre opérateur.

Enfin, la clôture d’un incident devrait exiger un test indépendant. Un ticket marqué « corrigé » n’établit pas que l’exposition a disparu. La même méthode qui a détecté le défaut doit être rejouée depuis l’extérieur, puis répétée après un délai ou un événement de basculement. La responsabilité devient ainsi une propriété vérifiable du système en fonctionnement, plutôt qu’une promesse administrative.

Les normes disponibles avant l’incident

L’évaluation historique doit distinguer ce qui était documenté avant mars 2013 de ce qui a été normalisé ou largement diffusé plus tard. Trois références antérieures sont centrales. La RFC 5358 décrivait depuis 2008 l’utilisation de résolveurs récursifs accessibles comme réflecteurs et recommandait de limiter le service aux clients prévus. [4] Le BCP 38 appelait depuis 2000 au filtrage des adresses source aux frontières clients. [5] Le BCP 84 adaptait ce principe aux environnements multihomés et aux chemins asymétriques. [6]

Ces textes établissent l’existence de catégories de contrôle pertinentes avant l’attaque. Ils ne démontrent pas que chaque opérateur les avait déployées, qu’il connaissait l’état de tous ses équipements ou qu’une interface déterminée avait laissé passer un paquet particulier. Une norme publique est une référence pour évaluer une capacité ; elle n’est pas une mesure de la configuration réelle.

D’autres spécifications antérieures ou contemporaines aident à comprendre le comportement du protocole sans fournir, à elles seules, une preuve de déploiement. Les extensions DNS et les tailles de message possibles influencent la forme des réponses. [11] Le comportement des équipements traduisant les adresses et les ports peut aussi compter dans l’étude de certains chemins UDP. [12] Ces éléments doivent être utilisés avec précision, sans les transformer en explication automatique de chaque paquet de la campagne.

Le standard historique pertinent n’était donc pas la perfection. Il était la présence de deux moyens documentés pour supprimer deux conditions essentielles : l’accès récursif non voulu et la sortie de sources falsifiées. Une évaluation équitable demande ensuite des preuves propres à chaque réseau : configuration, tests, journaux, exceptions et réparations.

Cela évite deux anachronismes. Le premier serait d’affirmer que les opérateurs de 2013 ne disposaient d’aucune orientation sur la réflexion DNS ou l’usurpation. Les documents antérieurs contredisent cette affirmation. Le second serait de leur reprocher de ne pas avoir employé exactement des mécanismes normalisés ou développés plusieurs années après. La responsabilité historique doit se fonder sur les contrôles effectivement connus et praticables à l’époque, puis utiliser les avancées ultérieures pour améliorer la vérification actuelle.

Les références ultérieures comme outils de comparaison

Les mécanismes publiés après 2013 permettent de renforcer la défense et de poser de meilleures questions aux opérateurs contemporains. Les DNS Cookies peuvent, lorsque les deux parties les prennent en charge, fournir un signal supplémentaire contre certains échanges usurpés. [7] La réduction des réponses au type ANY limite une forme historiquement attractive d’amplification. [8] Les recommandations plus récentes sur l’architecture des grands services faisant autorité traitent de résilience, de distribution et d’exploitation à l’échelle. [9]

Aucun de ces textes ne prouve que le mécanisme correspondant était disponible sous la même forme, installé ou opérationnel pendant la campagne du 18 au 27 mars 2013. Ils ne remplacent pas non plus les deux contrôles fondamentaux. Un résolveur destiné à une population limitée doit toujours faire respecter cette limite. Un réseau capable de connaître les préfixes légitimes de son client doit toujours empêcher l’exportation de sources impossibles.

La possibilité de servir temporairement des données périmées en cas de difficulté de résolution, normalisée plus tard, peut contribuer à certaines stratégies de continuité. [13] Elle n’établit pas que les systèmes de Spamhaus ou de ses utilisateurs l’employaient pendant l’incident, ni qu’elle aurait résolu une saturation de liens. Elle illustre plutôt une règle générale : les mécanismes applicatifs et DNS doivent être reliés au domaine de défaillance qu’ils peuvent réellement traiter.

Les orientations opérationnelles de RIPE donnent aujourd’hui un cadre plus mûr pour l’hygiène, l’observation et la sécurité des opérations DNS. [14] Les présentations de RIPE et de DNS-OARC consacrées à l’amplification documentent le poids opérationnel des résolveurs exposés, les méthodes d’inventaire et les mesures de réduction. [16][17] Elles offrent des points de comparaison utiles pour construire des tests et des procédures de notification.

Les travaux de recherche permettent d’examiner la population des amplificateurs, la dynamique de l’exposition et les limites des mesures réalisées depuis différents points. [18] Des analyses plus récentes des défenses DNS pendant les DDoS aident à comparer les comportements, la distribution de charge et l’efficacité des contrôles dans des environnements modernes. [19] Là encore, il s’agit d’améliorer l’assurance présente, pas de réécrire le passé.

La bonne utilisation de ces références consiste à demander ce qu’un opérateur peut désormais démontrer : inventaire complet, récursion fermée, validation des sources, réponses bornées, séparation des rôles, basculement testé, journaux de coordination et contrôle externe après réparation. La mauvaise utilisation consisterait à présenter chaque mécanisme ultérieur comme un équipement standard dont l’absence en 2013 établirait automatiquement une faute.

Un programme moderne de vérification opérationnelle

Un programme crédible commence par une cartographie des surfaces exposées. Pour le DNS, l’organisation doit connaître tous les hôtes qui répondent, leur rôle récursif ou faisant autorité, les interfaces ouvertes, les populations autorisées et les dépendances de configuration. L’inventaire doit être rapproché d’observations externes afin de détecter les équipements oubliés et les différences entre la configuration prévue et le comportement réel.

La couverture doit être mesurée avec un dénominateur. Il faut pouvoir dire quelle proportion des adresses, interfaces, sites et versions a été testée. Un résultat positif isolé ne suffit pas à déclarer tout un parc fermé. Les nouvelles acquisitions, les migrations, les changements de fournisseur, les mises à niveau DNS et les basculements doivent déclencher une nouvelle campagne de contrôle.

Pour les frontières réseau, le programme doit associer chaque client ou segment aux préfixes qu’il peut légitimement émettre. Des essais sûrs et autorisés doivent confirmer que les sources invalides sont rejetées. Les chemins asymétriques et le multihoming nécessitent une méthode adaptée plutôt qu’une désactivation générale. Les changements BGP doivent provoquer un retest, car une politique auparavant correcte peut devenir trop permissive ou bloquer du trafic légitime.

Les défenses contre l’amplification doivent être testées selon leurs conditions réelles. Une limitation de débit peut réduire les émissions sans fermer l’accès. Une réponse ANY minimale peut diminuer la taille d’un type de réponse sans protéger toutes les autres. Les DNS Cookies ne produisent leur effet que dans les échanges compatibles. L’organisation doit donc décrire le risque traité, les prérequis, la couverture et le résultat observé, plutôt que d’énumérer des fonctionnalités.

Les exercices de continuité doivent inclure le DNS, l’anycast, le transit et les communications. Un basculement utile vérifie que les annonces atteignent les réseaux prévus, que la capacité existe sur les chemins entrants, que le trafic légitime survit au nettoyage et que les équipes peuvent joindre les fournisseurs. Les tests doivent aussi séparer le site web, les systèmes faisant autorité, les données distribuées et les services de soutien.

Lorsqu’un incident survient, la séquence doit être conservée : première détection, points de mesure, saturation observée, activation de la mitigation, changements de route, contacts avec les pairs, comportement des sites, récupération et nouvelle vérification. Cette chronologie permet de distinguer une coïncidence d’un effet probable et d’éviter qu’un chiffre agrégé soit attribué au mauvais composant.

La gouvernance n’a de valeur que si elle aboutit à une réparation observable. Chaque échec doit être confié à l’équipe qui contrôle le composant, avec un délai, une preuve attendue et un test de clôture. Les exceptions doivent expirer. Les résultats publiés doivent indiquer la méthode, la population testée, la période, les limites et les zones aveugles. Le but n’est pas de produire une conformité décorative, mais de réduire durablement la capacité exécutable qui permet la réflexion ou l’usurpation.

Les limites du dossier public

Le mécanisme de réflexion est mieux établi que l’échelle totale et l’attribution complète. Les comptes rendus de Cloudflare soutiennent la séquence générale, les débits observés depuis ses environnements, la participation de plus de 30 000 résolveurs et la forme d’amplification décrite. [1][2] Ils ne fournissent pas une cartographie exhaustive de tous les systèmes autonomes ayant émis des requêtes falsifiées ou des réponses réfléchies.

Le point exact de mesure de chaque maximum n’est pas entièrement documenté dans un jeu de données public commun permettant une reproduction indépendante. Il n’existe donc pas, dans ce dossier, de « pic universel » pouvant être attribué au réseau mondial. Le chiffre de 300 Gbit/s doit rester une observation côté fournisseur. La formule sur un Internet presque brisé doit rester une construction publicitaire, pas un constat de panne globale.

L’impact sur les tiers est plausible au regard du déplacement de la charge vers des réseaux partagés, mais il n’est pas quantifié dans son ensemble. Les sources ne permettent pas d’énumérer toutes les organisations ayant subi une congestion, toutes les régions touchées ni la durée de chaque dégradation. Elles ne justifient pas l’invention d’une interruption d’un point d’échange ou d’un service indépendant.

La connaissance des opérateurs reste également incertaine. Une exposition peut être détectée depuis l’extérieur sans révéler si l’opérateur en avait été averti, s’il avait reçu un rapport d’abus, s’il avait tenté une réparation ou si une exception était volontaire. Ces questions demanderaient des tickets, des journaux, des communications et des témoignages qui ne figurent pas dans le dossier retenu.

L’identité de l’assaillant et la responsabilité juridique ne doivent pas être déduites du seul mécanisme technique. Une source ultérieure relative à une arrestation fournit un élément de contexte, mais elle ne constitue pas une adjudication complète de chaque action, de chaque phase et de chaque dommage. [3] Le dossier ne permet pas non plus de répartir avec précision la causalité entre le système ayant émis les requêtes, les réseaux ayant laissé passer les sources usurpées, les résolveurs, les chemins de transport et les décisions de mitigation.

Ces inconnues ne sont pas des défauts à combler par intuition. Elles définissent la portée honnête de la conclusion. Il est possible d’affirmer qu’un résolveur répondait, qu’une source pouvait être usurpée, qu’un lien a reçu une charge mesurée ou qu’une route a changé lorsque des preuves le montrent. Il n’est pas possible de convertir automatiquement ces faits en connaissance, intention, faute légale ou part exacte de dommage.

La prudence ne diminue pas la responsabilité opérationnelle. Elle la rend plus précise. Un opérateur n’a pas besoin d’être déclaré cause unique de l’incident pour devoir fermer un service indésirable ou corriger une frontière permissive. La réparation peut être exigée sur la base du contrôle pratique, tout en laissant ouvertes les questions plus larges que le dossier ne tranche pas.

Le test de responsabilité réseau

L’incident Spamhaus fournit un test en trois dimensions : capacité de contrôle, qualité des preuves et efficacité de la réparation. La première question est de savoir qui pouvait modifier le chemin exécutable. Un opérateur de résolveur pouvait restreindre la récursion. Un réseau d’accès pouvait valider les sources. Un fournisseur de mitigation pouvait modifier les annonces, le nettoyage et la distribution anycast. Un transitaire pouvait agir sur ses frontières clients et ses capacités. Un exploitant de service pouvait séparer ses composants et améliorer sa continuité.

La deuxième question porte sur la preuve. Une politique ne suffit pas si aucun test ne démontre son application. L’opérateur doit pouvoir montrer la configuration active, la population couverte, les résultats externes, les exceptions et la chronologie des changements. Pour le routage, il faut connaître les annonces et les interfaces. Pour la disponibilité, il faut nommer le service et le point d’observation. Pour les mesures publiques, il faut indiquer l’emplacement et la méthode.

La troisième question est celle de la réparation. Une correction doit modifier le comportement. Un résolveur auparavant accessible ne doit plus fournir de récursion à une sonde non autorisée. Un paquet portant une source impossible ne doit plus quitter la frontière testée. Une architecture anycast doit conserver un chemin utilisable sous basculement. Une communication de reprise doit distinguer le site, le DNS, les données distribuées et les réseaux de soutien. Le résultat doit être revérifié depuis l’extérieur.

Ce test ne dépend pas d’un accord moral avec les activités de Spamhaus. Il n’exige pas non plus d’attribuer à une seule organisation une campagne distribuée. Il part d’une réalité plus simple : des logiciels, des interfaces, des règles d’accès et des routes ont produit un comportement observable. La responsabilité appartient à l’opérateur capable de modifier ce comportement dans son domaine.

Les deux contrôles antérieurs à l’incident restent le noyau de l’analyse. Fermer la récursion réduit la population des réflecteurs. Valider les adresses source retire à l’assaillant la capacité de diriger les réponses vers une victime choisie. L’un ne remplace pas l’autre. Leur indépendance explique pourquoi la chaîne pouvait persister malgré la correction de quelques éléments et pourquoi une action coordonnée à grande échelle est nécessaire.

Les contrôles modernes renforcent cette base : réponses moins attractives, signaux anti-usurpation, architectures faisant autorité résilientes, inventaires externes et meilleures procédures de coordination. Ils doivent être évalués selon leur couverture effective. Une fonctionnalité activée sur un sous-ensemble inconnu ne constitue pas une assurance globale.

Enfin, le test reconnaît les limites de compétence. Un point d’échange ne doit pas être accusé d’une panne sans mesures propres. Un transitaire ne doit pas recevoir automatiquement la responsabilité de toute source falsifiée transportée loin de la frontière d’origine. Spamhaus ne doit pas être tenu responsable de résolveurs qu’il ne contrôlait pas. Cloudflare ne doit pas voir ses mesures transformées en recensement universel. La précision des limites fait partie de la responsabilité autant que la précision des contrôles.

Conclusion

La campagne de mars 2013 n’est pas importante seulement parce qu’un fournisseur a annoncé un débit spectaculaire. Elle l’est parce qu’elle rend visible une défaillance répartie. Des requêtes à faible débit ont pu porter des adresses source falsifiées. Des résolveurs accessibles ont fourni des réponses amplifiées. Le routage, l’anycast, le peering et le transit ont déterminé où ces réponses convergeaient. Les services et réseaux de soutien ont présenté des limites de continuité différentes.

Aucun slogan ne remplace la cartographie de cette chaîne. Le chiffre de 300 Gbit/s reste une observation attribuée à Cloudflare, pas un état de l’ensemble d’Internet. L’expression selon laquelle Internet aurait presque été brisé reste un cadrage publicitaire, pas une conclusion de panne mondiale. L’indisponibilité du site de Spamhaus ne prouve pas l’arrêt global de ses données DNSBL, et la continuité déclarée de ces données ne permet pas de nier toute dégradation locale. [1][2][3]

La leçon opérationnelle est plus exigeante que la légende. Chaque opérateur doit savoir ce qu’il contrôle, conserver des preuves de l’état réel de ses systèmes et démontrer la réparation. Les résolveurs doivent refuser les clients non autorisés. Les frontières doivent rejeter les sources impossibles. Les fournisseurs doivent documenter les routes, les capacités et la coordination. Les exploitants de services doivent distinguer leurs couches de disponibilité.

Là où les preuves s’arrêtent, la conclusion doit rester ouverte : distribution complète des systèmes autonomes, impact sur tous les tiers, connaissance de chaque opérateur, identité technique de tous les acteurs, responsabilité juridique et partage causal exact. Cette retenue n’affaiblit pas le constat central. Elle empêche simplement que l’analyse d’infrastructure devienne une narration de certitudes non démontrées.

La responsabilité réseau se mesure finalement par une question concrète : l’opérateur capable de modifier une étape du chemin l’a-t-il effectivement corrigée, et peut-il prouver que cette correction fonctionne encore ? Pour la campagne Spamhaus de 2013, ce test conduit à quatre exigences durables : limiter la récursion, valider les sources, rendre les décisions de routage auditables et vérifier la continuité depuis plusieurs chemins indépendants.

Le DDoS de Spamhaus en 2013 a fait de la récursion DNS ouverte un test de responsabilité réseau