Attaque DNS racine de 2002: résilience et responsabilité

Résumé

Le 21 octobre 2002, une attaque par déni de service distribué a matériellement dégradé d’importants chemins vers le système de serveurs racine du DNS. CAIDA a observé des changements brusques de temps aller-retour depuis des points de surveillance nommés, la durée variant selon l’identité racine logique. [1]
L’ICANN a décrit plus tard neuf des 13 adresses logiques de serveurs racine comme « submergées ». Cette formulation attribuée témoigne de l’ampleur de l’attaque, sans prouver que neuf services complets ont disparu partout ni que chaque résolveur et chaque utilisateur ont échoué. [5]
CAIDA a conclu que l’impact visible sur l’exploitation mondiale du réseau était faible. La mise en cache récursive, le comportement de nouvelle tentative et la multiplicité des identités racine logiques ont contribué à séparer la forte pression sur les serveurs et les chemins d’une défaillance universelle des transactions. [1][20][21]
L’analyse de paquets de CAIDA a couvert les liaisons racine E, I, K et M par intervalles de dix minutes commençant peu après l’événement. Ces observations constituent des preuves directes pour les liaisons surveillées, pas un recensement de chaque instance racine, résolveur, route ou application. [2][3]
Les RFC 2870 et RFC 3258 montrent que la capacité, la connectivité diversifiée, la journalisation, la coopération et le service d’autorité distribué étaient des contrôles reconnus avant l’attaque. Cela ne prouve pas que chaque opérateur avait déployé chaque contrôle à la date de l’attaque. [8][9]
Les orientations ultérieures sur l’anycast, le RSSAC, le SSAC et les grands services d’autorité fournissent des critères de remédiation et de mesure. Elles constituent un matériau de comparaison postérieur, pas des obligations légales rétroactives ni une preuve de la topologie exacte de 2002. [6][10]-[16]
La responsabilité était répartie entre les opérateurs de serveurs racine, les réseaux de transit et d’accès, les opérateurs de résolveurs et les organes de coordination. Aucune institution ne contrôlait à elle seule chaque serveur, route, cache, filtre ou transaction utilisateur.
La norme de responsabilité est opérationnelle: les enregistrements identifient l’autorité, tandis que des routes joignables, des réponses correctes, la continuité des résolveurs, une atténuation bornée et une restauration multi-vues prouvent la continuité du service.

Un registre d’autorité ne garantit pas le service

Une entrée du fichier des serveurs racine peut indiquer à un résolveur récursif où un serveur racine DNS devrait se trouver. Un enregistrement de la zone racine peut identifier l’autorité responsable d’une délégation. Aucun de ces enregistrements ne peut faire traverser à un paquet une route congestionnée, contraindre une instance faisant autorité à répondre, préserver la capacité sous un flot ni prouver que la transaction d’un utilisateur s’est achevée.

Cette distinction est devenue opérationnellement importante le 21 octobre 2002, lorsqu’une attaque par déni de service distribué a envoyé un fort flux de trafic vers les adresses logiques du système de serveurs racine du DNS. L’événement est souvent réduit à un décompte spectaculaire de serveurs. L’ICANN a décrit plus tard neuf des 13 adresses logiques de serveurs racine comme ayant été « submergées ». Cette formulation est significative, mais elle ne constitue pas un compte rendu complet de la disponibilité du service.

Elle n’établit pas que neuf services complets ont disparu en tout lieu, que chaque résolveur récursif devait contacter une racine au même moment ni que les utilisateurs ont subi une défaillance universelle. [5]

La question de la responsabilité est donc plus exigeante que la simple vérification qu’une adresse a été attaquée. Elle oblige à séparer plusieurs couches souvent confondues: le trafic arrivant sur une liaison de serveur, la réponse visible depuis un chemin réseau particulier, le comportement de résolveurs récursifs ayant des états de cache différents, et le succès ou l’échec des transactions utilisateur achevées. Chaque couche a ses propres opérateurs, ses propres preuves et ses propres frontières de défaillance.

Les enregistrements faisant autorité comptent parce qu’ils établissent quelles identités de service les résolveurs sont censés utiliser. Ce sont des registres essentiels de délégation et d’autorité. Mais un registre n’est pas le système en cours d’exécution.

La continuité opérationnelle dépend d’instances d’autorité capables de répondre correctement, de routes qui restent joignables, d’une capacité suffisante, d’une répartition entre domaines de défaillance, de résolveurs qui exploitent efficacement les informations en cache, de réseaux qui limitent le trafic nuisible là où ils le peuvent, et d’opérateurs capables de coordonner l’atténuation et la restauration.

Retirez la joignabilité de la racine DNS de l’événement et il n’y a plus de question de continuité de service. Retirez la mise en cache des résolveurs et la pression sur les serveurs est trop facilement confondue avec un préjudice utilisateur équivalent. Retirez la répartition du service d’autorité et la conception de la résilience ne peut pas être évaluée. Retirez la diversité des routes et l’analyse ignore comment la demande atteint une capacité saine. Retirez le filtrage des adresses source et la responsabilité à la périphérie d’origine du trafic disparaît.

Retirez les points d’observation des mesures et des observations locales deviennent des affirmations globales injustifiées. Retirez la coordination entre opérateurs et il n’existe plus de compte rendu crédible de la manière dont un service distribué détecte, atténue et déclare la reprise.

L’attaque de 2002 a rendu ces dépendances visibles. Elle n’a pas montré qu’une institution possédait un contrôle exclusif. Elle a montré que le service perçu par les utilisateurs est assemblé à partir d’enregistrements, de code en exécution, de routage, de caches et de décisions opérationnelles autonomes. La responsabilité doit suivre ces contrôles pratiques et les preuves que chaque contrôleur peut produire.

Ce qui a été observé le 21 octobre 2002

Le compte rendu de mesure contemporain de CAIDA a signalé une dégradation brutale du temps aller-retour vers 22 h 00 UTC. Depuis le point d’observation de l’UCSD, toutes les racines surveillées à l’exception de I et M ont montré un changement de performance, mais la durée n’était pas uniforme. CAIDA a signalé des effets durant environ une heure pour F, G et L, environ cinq à dix minutes pour A et B, et un peu plus de dix minutes pour J. [1]

Ces observations fournissent la preuve d’un événement grave. Elles ne fournissent pas une carte universelle du service racine depuis chaque réseau. Les mesures dépendaient de moniteurs situés à San Diego et San Jose et décrivaient donc le service tel qu’il était visible sur des chemins particuliers depuis des emplacements particuliers. Une adresse racine qui répondait mal depuis un moniteur pouvait présenter une condition différente à un résolveur utilisant un autre fournisseur amont, une autre route ou un autre chemin géographique.

Inversement, une racine qui semblait réactive depuis un site de mesure pouvait rester difficile à joindre depuis un autre réseau.

Cette limite n’est pas une faiblesse propre à CAIDA. C’est une propriété fondamentale de la mesure des services distribués. Un moniteur enregistre ce que son chemin lui permet de voir. Ses résultats ne deviennent largement significatifs que lorsque l’emplacement, la métrique, l’intervalle de temps et la cible sont indiqués avec la conclusion.

CAIDA a également conclu que l’impact visible sur l’exploitation mondiale du réseau était faible. [1] Cette conclusion contraint toute reformulation de l’attaque. Elle exclut de traiter un trafic intense et des changements de performance des serveurs racine comme une preuve automatique de défaillance universelle des utilisateurs. Elle exige aussi une explication: l’architecture DNS contient des tampons entre une adresse racine faisant autorité et une transaction individuelle, notamment la mise en cache récursive et la disponibilité de plusieurs identités de service racine.

L’historique de l’opérateur de D-Root identifie indépendamment le 21 octobre 2002 comme la date d’une attaque massive et note que les opérateurs ont ensuite préparé une analyse de l’événement. [4] Ce registre corrobore la date et la reconnaissance opérationnelle de l’incident. Il n’établit pas, à lui seul, des conditions identiques pour chaque identité racine ou chaque instance physique.

L’analyse de paquets ultérieure de CAIDA fournit une autre vue bornée. Elle a examiné le trafic collecté sur les liaisons desservant les racines E, I, K et M, en commençant peu après l’attaque, et a regroupé les observations en intervalles de dix minutes. Ses distributions de requêtes et de clients observés sont des mesures directes issues de ces liaisons. [2] Le travail plus large de CAIDA sur le trafic racine explique l’ensemble de données et la méthodologie dans lesquelles s’inscrivent ces observations. [3]

Les données des liaisons E, I, K et M ne doivent pas être traitées comme un recensement de chaque identité racine, instance physique, résolveur, réseau d’accès ou application. Elles ont commencé après le début de l’attaque, ont couvert des liaisons nommées et ont utilisé des intervalles d’observation définis. Elles sont précieuses précisément parce que leur frontière est connaissable. L’usage correct de ces preuves consiste à indiquer ce qui est apparu sur les liaisons surveillées et à quel moment, puis à résister à la transformation de ces échantillons en totaux non étayés pour l’ensemble du système.

Trois descriptions spécifiques aux sources peuvent donc coexister sans contradiction:

CAIDA a observé des changements de performance de chemin dont la durée différait selon l’identité racine depuis ses emplacements de surveillance. [1]
CAIDA a ensuite analysé les paquets et les clients apparents sur des liaisons sélectionnées E, I, K et M par intervalles de dix minutes. [2]
La comparaison de l’ICANN en 2007 a décrit neuf des 13 adresses logiques de serveurs racine comme submergées pendant l’attaque de 2002. [5]

Elles observent des objets différents. L’une concerne la performance mesurée des chemins, une autre les paquets sur des liaisons sélectionnées, et la troisième est un résumé institutionnel ultérieur centré sur des adresses logiques. Une analyse responsable conserve ces distinctions.

Pourquoi « neuf sur treize » n’est que le début de l’analyse

Le nombre treize renvoie aux identités logiques des serveurs racine. Une identité logique n’équivaut pas nécessairement à une machine, un site ou une route unique. Sa réalisation opérationnelle dépend de la manière dont l’opérateur responsable déploie la capacité d’autorité et annonce l’adresse de service.

Ce point compte même si la distribution physique et topologique en 2002 était moins étendue que le déploiement ultérieur du système racine. Les preuves publiques figées n’énumèrent pas chaque instance physique, route active ou disposition locale d’atténuation le jour de l’attaque. Elles ne peuvent donc pas soutenir une reconstruction précise des matériels ou sites simultanément joignables depuis chaque partie de l’Internet.

La formulation de l’ICANN doit être préservée sous sa forme attribuée: neuf des 13 adresses logiques de serveurs racine ont été décrites comme submergées. [5] « Submergées » indique que l’attaque a débordé d’importants chemins ou capacités de service. Cela ne définit pas une frontière de panne universelle. Cela ne dit pas que toute la capacité d’autorité associée à chaque adresse a échoué partout. Cela ne révèle pas la décision de nouvelle tentative de chaque résolveur ni son état de cache. Cela ne compte pas les transactions achevées.

Un décompte d’adresses de serveurs omet au moins quatre dimensions.

Premièrement, il omet le point d’observation. La joignabilité est relationnelle: un résolveur atteint une adresse par une route précise depuis un réseau précis. Un échec de réponse observé en Californie constitue une preuve sur ce chemin et ce moment, pas une observation directe depuis l’Europe, l’Afrique, l’Asie ou un autre réseau nord-américain.

Deuxièmement, il omet le temps. Les changements de performance signalés par CAIDA n’ont pas tous duré aussi longtemps. [1] Un décompte sans intervalle de temps peut combiner une brève dégradation à une adresse avec une condition plus longue à une autre et les faire paraître opérationnellement identiques.

Troisièmement, il omet la distribution du service. Une identité logique peut être représentée par plus d’un site de service lorsqu’un schéma d’adressage distribué est déployé. L’existence, l’étendue et le comportement d’une telle distribution doivent être démontrés pour la date et l’identité discutées. Ils ne peuvent pas être déduits d’une topologie ultérieure.

Quatrièmement, il omet la couche des résolveurs. Un résolveur récursif peut répondre en utilisant des renvois en cache valides sans envoyer de requête racine pour chaque demande utilisateur. Un autre résolveur peut avoir besoin d’informations fraîches, réessayer une autre identité racine ou rencontrer un autre chemin. Le titre sur les adresses de serveurs ne peut pas résoudre ces différences.

Le décompte est par conséquent une preuve de la gravité de l’attaque, pas une mesure autosuffisante du préjudice utilisateur. La bonne question n’est pas de savoir si le nombre doit être minimisé. Elle est de savoir ce que le nombre a mesuré, ce qu’il a omis et quelles preuves supplémentaires sont nécessaires pour le traduire en conclusion de service.

Cette distinction protège la responsabilité au lieu de la diluer. Si chaque adresse surchargée est assimilée à une disparition universelle du service, les opérateurs ne peuvent pas dire quels contrôles ont réellement contenu le préjudice. La mise en cache, la capacité d’autorité alternative, la diversité des routes et la coordination deviennent invisibles. Si le décompte est écarté parce que de nombreuses transactions ont encore réussi, la pression de l’attaque sur l’infrastructure critique est sous-estimée.

Un compte rendu défendable doit tenir les deux faits ensemble: l’attaque a matériellement dégradé d’importants chemins du service racine, tandis que les preuves disponibles n’établissent pas une défaillance universelle.

La mise en cache des résolveurs distingue la pression sur l’infrastructure du préjudice pour les utilisateurs

Le processus de résolution DNS n’exige pas que chaque requête utilisateur se rende jusqu’à un serveur racine. Les résolveurs récursifs conservent les informations DNS pendant la durée de vie autorisée du cache. Lorsqu’un résolveur détient déjà le renvoi nécessaire pour poursuivre la résolution, il peut utiliser cette information non expirée sans contacter un serveur racine pour cette transaction. [20], [21]

La mise en cache modifie donc la relation entre une attaque contre l’infrastructure d’autorité et l’expérience visible pour les utilisateurs. Elle crée un tampon de service temporaire. Ce tampon n’est ni illimité ni uniforme.

Deux résolveurs peuvent subir la même attaque et connaître des résultats différents parce que leurs caches contiennent des enregistrements différents avec des durées de vie restantes différentes. L’un peut déjà posséder le renvoi requis pour un domaine populaire. Un autre peut devoir interroger la racine pour une information qu’il n’a pas mise en cache ou dont la copie en cache a expiré. Leurs routes amont peuvent aussi différer. Même s’ils contactent la même adresse racine logique, ils peuvent ne pas observer la même condition de réponse.

Cela explique pourquoi une attaque grave contre les adresses de serveurs racine ne produit pas nécessairement une défaillance aussi grave et simultanée dans les applications. Cela explique aussi pourquoi la télémétrie des serveurs ne peut pas, à elle seule, trancher la question de l’impact utilisateur. Un opérateur racine peut démontrer que le trafic a bondi ou que les réponses se sont dégradées sur une instance. Cette preuve est essentielle, mais elle ne montre pas quels résolveurs récursifs avaient besoin du service touché pendant l’intervalle ni quelles transactions utilisateur ont échoué.

L’inférence inverse est également dangereuse. Un préjudice limité immédiatement visible pour les utilisateurs ne signifie pas que l’événement d’infrastructure était sans conséquence. Les données en cache vieillissent. Une perte prolongée de service d’autorité joignable exposerait progressivement les résolveurs qui ont besoin d’informations qui ne sont plus disponibles localement. L’architecture peut absorber un choc sans rendre ce choc insignifiant.

La mise en cache appartient à la carte des responsabilités parce que les opérateurs de résolveurs récursifs contrôlent des aspects importants de ce tampon. Ils gèrent le comportement du cache, les nouvelles tentatives, le fichier des serveurs racine et la surveillance orientée utilisateur. Leurs preuves peuvent montrer si les résolveurs ont continué à répondre, ont basculé les requêtes entre identités racine, ont rencontré des délais d’attente ou ont épuisé les informations utiles en cache. Sans données côté résolveur, une évaluation reste enfermée entre la détresse des serveurs et l’expérience utilisateur anecdotique.

Le système de serveurs racine et la population des résolveurs récursifs fonctionnent également sur des horloges différentes. Une instance racine peut subir un pic de trafic immédiat. Un moniteur peut observer un temps aller-retour accru quelques secondes ou minutes plus tard. Les effets sur les résolveurs dépendent de l’état du cache et du comportement de nouvelle tentative. Une transaction utilisateur ajoute la temporisation et la tolérance propres à l’application. Combiner ces horloges en une seule affirmation telle que « le DNS était en panne » efface la chaîne causale.

La conclusion bornée rapportée par CAIDA — selon laquelle l’impact visible sur l’exploitation mondiale du réseau était faible — s’inscrit dans ce modèle en couches. [1] Elle ne doit pas être généralisée en une affirmation selon laquelle aucun utilisateur n’a été touché, car les taux exacts de défaillance au niveau utilisateur ne sont pas disponibles. Elle ne doit pas non plus être écartée au profit d’un décompte dramatique d’adresses. Elle prouve que le système au sens large, y compris les caches et la joignabilité d’autorité restante, a continué à fournir un service substantiel malgré une pression intense.

La responsabilité exige donc à la fois des preuves de pression et des preuves de continuité. Les premières montrent où l’infrastructure a subi une charge. Les secondes montrent si les résolveurs et les transactions ont continué à obtenir des réponses opportunes et correctes. Aucune ne remplace l’autre.

L’exploitation distribuée change la détention de la résilience

Le système de serveurs racine du DNS est distribué non seulement dans sa topologie, mais aussi dans son autorité opérationnelle. Les opérateurs individuels de serveurs racine contrôlent leurs propres instances, la planification de capacité, la connectivité amont, le filtrage local, la surveillance et la réponse aux incidents. Les réseaux de transit et d’accès contrôlent d’autres parties du chemin. Les opérateurs de résolveurs récursifs contrôlent les caches et les nouvelles tentatives. Les organes de coordination et de conseil relient ces domaines sans effacer leur autonomie.

Cela signifie que la responsabilité ne peut pas être réduite à l’organisation associée à la zone racine ni à l’institution qui a publié plus tard une fiche d’information. L’ICANN, les fonctions IANA et les structures liées au RSSAC ont des rôles de zone racine, de coordination et de conseil. Elles ne constituaient pas un système de commandement unique opérant chaque instance racine pendant l’attaque de 2002.

La distinction entre un teneur de registres et un opérateur est centrale. Les enregistrements de la zone racine et du fichier des serveurs racine identifient quels services logiques détiennent l’autorité. L’exactitude de ces enregistrements est indispensable: des informations d’autorité incorrectes orienteraient les résolveurs vers le mauvais service. Mais des enregistrements corrects ne peuvent pas garantir que les routes sont disponibles, qu’une instance dispose de capacité ou qu’un réseau amont filtre le trafic nuisible.

La continuité opérationnelle est produite par les parties qui contrôlent ces couches. Un opérateur racine peut ajouter de la capacité, distribuer le service, diversifier les fournisseurs amont et collecter la télémétrie des instances. Un fournisseur de transit peut provisionner des chemins, gérer la congestion et appliquer des contrôles de validité des sources dans son domaine. Un réseau d’accès peut limiter le trafic source invraisemblable quittant les réseaux clients. Un opérateur de résolveur peut maintenir un comportement de cache et de nouvelle tentative fiable.

Les organes de coordination peuvent établir des attentes partagées et des formats de preuve. Aucun rôle ne peut remplacer tous les autres.

Cette distribution empêche une attribution simple et exclusive de la faute, mais elle n’élimine pas la responsabilité. Elle rend la responsabilité plus précise. Chaque opérateur doit être évalué au regard des contrôles qu’il possédait réellement, des preuves disponibles à l’époque et des actions qu’il pouvait raisonnablement entreprendre sans assumer des pouvoirs détenus ailleurs.

Pour les opérateurs racine, les questions pertinentes comprennent: les requêtes légitimes pouvaient-elles atteindre une capacité d’autorité utilisable, la connectivité était-elle assez diversifiée pour éviter un goulot d’étranglement unique, la surveillance distinguait-elle un problème d’instance d’un problème de route plus large, et la restauration pouvait-elle être démontrée depuis l’extérieur du réseau propre de l’opérateur?

Pour les réseaux de transit et d’accès, les questions concernent la capacité des chemins, le comportement de routage et les contrôles à la périphérie du réseau. Un opérateur racine ne peut pas valider directement les adresses source sur chaque réseau d’accès d’origine. Un fournisseur d’accès ne peut pas dicter la manière dont chaque service racine distribue sa capacité. Leurs devoirs sont différents parce que leurs contrôles sont différents.

Pour les opérateurs de résolveurs, les questions concernent la continuité du service aux utilisateurs, le comportement du cache, les résultats des nouvelles tentatives et la capacité de distinguer la détresse racine amont des défaillances locales du résolveur ou de l’accès.

Pour les organes de coordination, la responsabilité concerne la qualité des attentes communes, l’échange d’informations, l’analyse des incidents et des métriques comparables — pas un pouvoir fictif d’adresser des commandements instantanés à chaque service exploité de manière indépendante.

Les utilisateurs occupent la position la moins habilitée. Ils peuvent observer des transactions lentes ou échouées, mais ne peuvent ordinairement pas inspecter la charge des liaisons racine, les changements de routage, le contenu des caches ni la coordination entre opérateurs. Un système qui place la charge de la preuve sur les utilisateurs inverserait la structure de contrôle. Les preuves doivent provenir des opérateurs qui détiennent la télémétrie pertinente.

La responsabilité répartie n’est donc ni une souveraineté centralisée ni une ambiguïté opérationnelle. C’est une carte de contrôle. Cette carte permet de demander qui pouvait observer une condition, qui pouvait la modifier, qui dépendait d’une autre partie et quelles preuves devraient subsister pour un examen ultérieur.

La capacité et la diversité étaient des contrôles reconnus avant l’attaque

L’événement de 2002 ne s’est pas produit dans un vide conceptuel. La RFC 2870, publiée avant l’attaque, énonçait les exigences opérationnelles des serveurs de noms racine. Elle traitait d’un service conforme aux normes, d’une capacité supérieure au pic de demande mesuré, d’une connectivité diversifiée, d’un fonctionnement exclusivement faisant autorité, de la journalisation et de la coopération dans l’analyse de sécurité. [8]

Ces attentes sont directement pertinentes pour l’attaque car elles identifient les types de contrôles qui rendent l’infrastructure d’autorité plus résiliente. La marge de capacité peut absorber une demande anormale jusqu’à un certain point. La connectivité diversifiée peut réduire la dépendance à un fournisseur ou à un chemin unique. Le fonctionnement exclusivement faisant autorité restreint le rôle du service. La journalisation et l’analyse coopérative soutiennent la détection et la reconstruction.

Le document ne peut cependant pas prouver l’état de déploiement de chaque opérateur le 21 octobre 2002. Une exigence opérationnelle dans une RFC ne prouve pas que chaque identité racine avait mis en œuvre la même architecture, possédait une capacité équivalente ou enregistrait la même télémétrie. Elle n’établit pas non plus une obligation légale, une négligence ou un manquement. Ces conclusions exigeraient des preuves au-delà du dossier technique fourni ici.

La RFC 2870 est mieux utilisée comme contexte antérieur à l’événement. Elle démontre que la capacité, la diversité de connectivité, la journalisation et la coopération étaient déjà comprises comme des contrôles opérationnels matériels. [8] Elle permet une enquête de responsabilité dans ces domaines sans prétendre que l’architecture ultérieure était déjà universelle. Elle ne répond pas à elle seule à l’enquête.

La RFC 3258, publiée en avril 2002, décrivait l’utilisation d’adresses unicast partagées pour distribuer le service de noms faisant autorité. [9] Cette conception permet à une adresse de service d’être annoncée depuis plusieurs sites, le routage déterminant quel site reçoit une requête. Elle introduit aussi ses propres frontières opérationnelles: le placement compte, le comportement de routage compte et les données d’autorité doivent rester cohérentes à travers le service distribué.

Le moment de publication est important mais doit être traité avec prudence. La RFC 3258 montre que le service d’autorité distribué par le routage était documenté avant l’attaque d’octobre. Elle n’établit pas que chaque identité racine l’avait déployé, que tous les déploiements étaient équivalents ni que le système racine possédait déjà son empreinte anycast ultérieure.

La capacité et la distribution résolvent aussi des problèmes différents. Davantage de capacité sur un site peut résister à un flot local plus important, mais ce site reste dépendant des routes et des liaisons amont qui le desservent. Davantage de sites peuvent répartir la demande et réduire la défaillance partagée, mais la distribution n’est utile que lorsque les routes dirigent les requêtes légitimes vers une capacité joignable et que les instances fournissent des réponses cohérentes. La diversité des routes sans capacité de service suffisante peut simplement exposer davantage de chemins surchargés.

La capacité de service sans diversité des routes peut rester injoignable.

L’attaque teste par conséquent une chaîne plutôt qu’un contrôle unique:

L’enregistrement d’autorité doit identifier le service logique correct.
Le routage doit livrer les requêtes à une instance opérationnelle.
Le chemin et l’instance doivent disposer d’une capacité utilisable suffisante.
Les instances distribuées doivent renvoyer des réponses d’autorité cohérentes.
Le comportement du résolveur doit exploiter efficacement le service disponible.
La surveillance doit révéler quel maillon de la chaîne est altéré.
Les opérateurs doivent se coordonner lorsque le maillon altéré franchit des frontières organisationnelles.

Chaque maillon a une exigence de preuve. Un fichier de configuration peut prouver l’autorité prévue. Une observation de route peut montrer la joignabilité annoncée. La télémétrie d’instance peut montrer la charge et le comportement de réponse. Les mesures des résolveurs peuvent montrer la résolution pratique. Les tests de transaction peuvent montrer l’achèvement côté utilisateur. Un compte rendu crédible après incident ne doit pas utiliser une catégorie comme substitut de toutes les autres.

L’unicast partagé et le danger de réécrire la topologie du jour de l’attaque

Les améliorations de résilience ultérieures peuvent faire paraître un système antérieur plus simple qu’il ne l’était. L’expansion ultérieure du système de serveurs racine par l’anycast est particulièrement exposée à cette distorsion.

La RFC 4786 a défini plus tard un modèle opérationnel d’anycast dans lequel la même adresse de service est annoncée depuis plusieurs sites discrets. [10] La RFC 7094 a développé des considérations architecturales supplémentaires pour la distribution anycast, notamment la relation entre topologie, routage et comportement du service. [11] La RFC 7720 a décrit plus tard des exigences de protocole et de déploiement pour le service de noms racine. [12]

Ces publications fournissent des critères de comparaison utiles. Elles expliquent pourquoi une adresse de service logique ne doit pas être automatiquement interprétée comme une machine physique unique et pourquoi le routage fait partie de la fourniture du service. Elles aident aussi à identifier les risques opérationnels: le placement peut être inégal, les routes peuvent déplacer la demande, les sites peuvent avoir des capacités différentes et les instances distribuées exigent un comportement de service cohérent.

Elles ne donnent pas licence de projeter le déploiement ultérieur dans le passé. Les preuves ne soutiennent ni une affirmation d’anycast racine universel le 21 octobre 2002 ni une carte complète, identité par identité, de la distribution le jour de l’attaque. La publication antérieure à l’événement de la RFC 3258 établit que la distribution par unicast partagé était une technique documentée. [9] Elle n’établit pas une mise en œuvre universelle.

La fiche d’information de l’ICANN en 2007 a comparé l’attaque racine ultérieure avec l’événement de 2002 et a attribué l’impact utilisateur plus faible de l’attaque ultérieure en partie au déploiement de l’anycast et à l’amélioration de la coordination entre opérateurs développée après 2002. [5] Cette comparaison soutient la conclusion que la distribution et la coordination sont devenues des contrôles de résilience plus significatifs. Elle ne convertit pas les contrôles ultérieurs en obligations rétroactives ni ne prouve qu’une remédiation unique explique toutes les différences entre les événements.

La comparaison responsable est causale et limitée. Le service distribué peut rendre plus difficile pour un flot dirigé vers une adresse logique de consommer toute la capacité associée, car le routage peut livrer le trafic vers plusieurs sites. La diversité des routes et des fournisseurs amont peut isoler certaines défaillances. Davantage de points d’observation peuvent révéler des différences régionales. La coordination peut aider les opérateurs à échanger des indicateurs d’attaque et à protéger le trafic légitime.

Mais l’anycast n’est pas une incantation. La même adresse sur plusieurs sites ne garantit pas une joignabilité égale, une charge équilibrée, des fournisseurs amont indépendants ni une capacité suffisante. Les politiques de routage déterminent où va le trafic. Un site mal placé ou sous-provisionné peut encore souffrir. Un changement de route peut rediriger la demande. Une surveillance qui agrège toutes les instances sous une étiquette logique unique peut cacher une détresse locale.

La valeur de responsabilité de la distribution réside donc dans des résultats démontrables. Les opérateurs devraient pouvoir montrer quelles instances desservaient une adresse, quelles routes les exposaient, comment le trafic s’est déplacé, si les réponses légitimes sont restées opportunes et correctes et si les défaillances sont restées contenues. L’existence d’une étiquette anycast ne suffit pas.

Cela ramène l’analyse au service en cours d’exécution. Une adresse logique inscrite dans le fichier des serveurs racine identifie où le service devrait être disponible. Un déploiement distribué crée davantage de manières de réaliser cette identité. Seule la mesure peut montrer si la réalisation a fonctionné depuis divers réseaux pendant une attaque.

La mesure doit identifier son horloge, sa couche et son point d’observation

Les preuves de 2002 montrent pourquoi la responsabilité de l’infrastructure exige un langage de mesure discipliné. Une affirmation sur « la racine » peut renvoyer à au moins cinq objets différents:

Couche de mesure	Ce qu’elle peut établir	Ce qu’elle ne peut pas établir seule
Charge de liaison et de paquets	Volume de trafic et clients apparents visibles sur une liaison surveillée pendant un intervalle défini	Les conditions sur chaque liaison racine ou le succès des transactions utilisateur
Performance de chemin	Joignabilité ou dégradation de réponse depuis un moniteur nommé vers une adresse logique	La joignabilité depuis chaque résolveur ou région
Service d’autorité	Si une instance observée a renvoyé des réponses DNS opportunes et correctes	L’état du cache et le comportement des résolveurs en aval
Résolveur récursif	Si la résolution s’est poursuivie grâce aux caches, aux nouvelles tentatives et aux racines disponibles	Les conditions rencontrées par chaque application ou utilisateur
Transaction achevée	Si une opération précise orientée utilisateur a réussi depuis un réseau défini	La santé globale de chaque composant DNS sous-jacent

Le compte rendu d’événement de CAIDA se situe principalement dans la couche de performance de chemin. Il a signalé des changements de temps aller-retour vers 22 h 00 UTC et des durées apparentes différentes parmi les racines surveillées. [1] Ces mesures constituent des preuves solides lorsqu’elles sont exprimées comme des observations depuis les sites indiqués. Elles deviennent plus faibles si elles sont transformées en affirmations de disponibilité globale.

L’analyse ultérieure E, I, K et M se situe à la couche des liaisons et des paquets. Ses regroupements par dix minutes fournissent une horloge et ses liaisons surveillées fournissent une portée. [2] Le contexte de l’ensemble de données explique comment ces observations de trafic racine ont été assemblées. [3] L’analyse peut caractériser ce que ces liaisons ont vu. Elle ne peut pas établir chaque origine physique, chaque route ni chaque résultat de résolveur.

Le compte rendu « neuf sur treize » de l’ICANN est un résumé par adresses logiques. [5] Il saisit l’ampleur de la pression sur les services nommés mais ne remplace pas les preuves de chemin, d’instance, de résolveur ou de transaction.

Une reconstruction crédible d’incident devrait donc attacher quatre qualificatifs à chaque affirmation majeure:

Objet:l’observation concernait-elle une adresse logique, une instance physique ou topologique, une liaison, une route, un résolveur ou une transaction?
Point d’observation:depuis quel réseau ou position de surveillance a-t-elle été observée?
Métrique:la preuve était-elle le volume de trafic, le temps aller-retour, le taux de réponse, l’exactitude, le comportement de délai d’attente ou la résolution achevée?
Intervalle:quand la condition a-t-elle commencé, comment la durée a-t-elle été mesurée et quand la restauration a-t-elle été confirmée?

Sans ces qualificatifs, différentes mesures peuvent être mises en contradiction alors qu’elles décrivent en réalité des couches différentes. Une liaison racine peut être fortement chargée pendant qu’un résolveur continue de répondre depuis le cache. Un moniteur peut voir une réponse dégradée depuis une route pendant qu’une autre route reste utilisable. Une transaction peut réussir même si une requête d’autorité tentée a expiré et qu’une nouvelle tentative a atteint une autre identité de service.

Les publications ultérieures du RSSAC offrent des critères de comparaison pour rendre les attentes et les mesures du service racine plus cohérentes. Le travail du RSSAC sur les attentes de service encadre le système de serveurs racine selon le service fourni, tandis que son cadre de mesure commun cherche des preuves comparables entre opérateurs. [13], [14] La RFC 9199 fournit de même des considérations opérationnelles ultérieures pour les grands systèmes de serveurs DNS d’autorité. [16]

Ces documents ultérieurs ne doivent pas être présentés comme des obligations qui régissaient chaque opérateur en 2002. Leur valeur est rétrospective et tournée vers l’avenir: ils montrent comment les preuves peuvent être structurées pour qu’un événement futur soit plus facile à déclarer, comparer et clôturer.

La responsabilité de la mesure s’applique aussi à la restauration. Le retour à la normale d’un graphique interne d’un opérateur est utile mais insuffisant si des résolveurs externes ne peuvent toujours pas obtenir de réponses. Le rétablissement d’un moniteur ne prouve pas le rétablissement partout. Le succès unique d’un résolveur n’établit pas une stabilité durable. La restauration devrait être soutenue par plusieurs couches: santé des instances, joignabilité des routes, exactitude d’autorité, succès des résolveurs et observations externes géographiquement ou topologiquement diverses.

L’objectif n’est pas un recensement global impossible. Les systèmes répartis en fournissent rarement un. L’objectif est une preuve bornée dont la portée est assez explicite pour que les décideurs puissent distinguer ce qui est connu, ce qui est inféré et ce qui reste inconnu.

Le contrôle pratique détermine la responsabilité pratique

Un service distribué a besoin d’un modèle de responsabilité qui suit le contrôle réel. Ce modèle peut être énoncé sans alléguer de faute.

Acteur	Contrôles principaux	Preuves attendues
Opérateurs de serveurs racine	Placement des instances, capacité d’autorité, diversité amont, filtrage local, surveillance et réponse aux incidents	Santé par instance et par liaison, comportement de réponse, contexte de route, calendrier d’atténuation et preuves de restauration
Réseaux de transit et d’appairage	Capacité des chemins, propagation des routes, gestion de la congestion et filtrage dans le domaine réseau	Changements de route et de trafic, chemins touchés, actions de filtrage et joignabilité depuis les réseaux pertinents
Réseaux d’accès	Contrôles à la périphérie client et plausibilité des adresses source dans leurs domaines	Portée du déploiement, exceptions, résultats de validation et observations liées à l’attaque lorsqu’elles sont disponibles
Opérateurs de résolveurs récursifs	Comportement du cache, nouvelles tentatives, fichier des serveurs racine et surveillance de la résolution orientée utilisateur	Succès dépendant du cache, schémas de délais d’attente et de nouvelles tentatives, résultats de sélection de racine et restauration des résolveurs
Organes de coordination et de conseil	Attentes partagées, échange d’informations, formats de preuve et analyse après incident	Avis opportuns, terminologie commune, mesures comparables, décisions enregistrées et conclusions bornées
Utilisateurs finaux	Requêtes d’application et observations locales	Symptômes de transaction, sans attendre des utilisateurs qu’ils reconstruisent l’état caché de l’infrastructure

Les opérateurs racine ont le contrôle le plus direct du service d’autorité, mais pas de chaque chemin de paquets. Ils peuvent distribuer la capacité, sélectionner les fournisseurs amont, surveiller les instances et appliquer des atténuations locales. Ils ne peuvent pas à eux seuls empêcher chaque réseau d’origine d’émettre du trafic nuisible.

Les réseaux de transit et d’appairage contrôlent si le trafic peut atteindre la capacité d’autorité sur des chemins particuliers. Ils peuvent influer sur la congestion, la disponibilité des routes et le déplacement de la demande entre les sites. Les preuves fournies ne reconstituent pas chaque décision de route ou d’appairage pendant l’attaque de 2002; aucune intervention de route spécifique ne doit donc être inférée.

L’absence de registre complet des routes est elle-même une leçon de responsabilité: les affirmations de service doivent être accompagnées d’assez de preuves de routage pour distinguer l’épuisement d’une instance d’une défaillance de chemin.

Les réseaux d’accès possèdent un contrôle différent. Ils sont en mesure d’évaluer si le trafic quittant leur domaine utilise des adresses source plausibles pour ce domaine. Cela n’en fait pas des contrôleurs du système racine. Cela les rend responsables d’une frontière de risque que les serveurs attaqués ne peuvent pas pleinement appliquer à destination.

Les opérateurs de résolveurs récursifs contrôlent le composant le plus proche de l’usage DNS ordinaire. La mise en cache peut préserver la continuité, les nouvelles tentatives peuvent localiser le service restant et la surveillance peut révéler si la pression racine se traduit par un échec de résolution. Un opérateur de résolveur ne contrôle pas la capacité racine, mais peut fournir des preuves décisives sur la propagation de l’impact utilisateur.

L’ICANN et les structures de coordination associées occupent une autre couche. Les rôles de zone racine et institutionnels rendent l’ICANN pertinent pour l’écosystème du service et pour l’analyse ultérieure, mais ne constituent pas un contrôle opérationnel exclusif sur des services racine exploités de manière indépendante. Il en va de même des structures consultatives: elles peuvent définir des attentes, faciliter la coordination et améliorer les preuves sans exploiter directement chaque instance.

L’avis du SSAC sur le risque de déni de service distribué et les contrôles DNS coordonnés, ainsi que le registre institutionnel répondant à ce travail, illustrent le développement ultérieur de cette couche de coordination. [6], [7] Le cadre d’atténuation des menaces des opérateurs de serveurs racine reflète de même un modèle distribué dans lequel la résilience naît des contrôles des opérateurs et de la coopération plutôt que d’un point de commandement unique. [15]

La propriété du contrôle doit être évaluée par trois questions.

Premièrement,qui pouvait observer la condition?Un opérateur racine voit la télémétrie des instances et des liaisons. Un réseau de transit voit le trafic et les routes dans son domaine. Un opérateur de résolveur voit les délais d’attente, l’usage du cache et les nouvelles tentatives. Un utilisateur voit les symptômes de transaction.

Deuxièmement,qui pouvait modifier la condition?L’opérateur racine peut ajouter ou redistribuer de la capacité de service. L’amont peut modifier le routage ou l’atténuation. Le réseau d’accès peut limiter le trafic source invraisemblable. L’opérateur de résolveur peut maintenir un comportement robuste de nouvelle tentative et de mise en cache. Un organe de coordination peut aligner les communications mais ne peut pas se substituer à ces actions opérationnelles.

Troisièmement,qui peut prouver la restauration?Aucun acteur ne dispose de toutes les pièces. Les opérateurs racine peuvent montrer la reprise du service, les réseaux peuvent montrer la normalisation des routes et du trafic, les opérateurs de résolveurs peuvent montrer le succès renouvelé de la résolution et des moniteurs externes peuvent tester la joignabilité. Une clôture crédible réunit ces registres sans prétendre qu’ils proviennent d’un seul contrôleur.

Ce modèle transforme la responsabilité en une discipline d’ingénierie. Il évite les deux extrêmes: blâmer une institution pour un système qu’elle n’exploitait pas exclusivement, et traiter l’exploitation distribuée comme une raison pour que personne n’ait à expliquer les résultats.

Le filtrage d’entrée relève de l’amont, pas d’un remède universel

Le filtrage des adresses source appartient à l’analyse parce que le trafic de déni de service peut exploiter des faiblesses loin du service attaqué. La RFC 2827 décrit le filtrage d’entrée destiné à réduire le trafic portant des adresses source falsifiées. [17] La RFC 3704 développe les considérations de filtrage, notamment les complications créées par les réseaux multi-domiciliés et le routage asymétrique. [18] La RFC 4732 traite le déni de service comme un problème d’ingénierie à l’échelle de l’Internet exigeant une attention dans plusieurs parties du réseau. [19]

Ces documents identifient une frontière de contrôle. Un réseau qui sait quelles adresses source devraient légitimement provenir de ses clients ou de ses réseaux aval est mieux placé pour rejeter le trafic invraisemblable qu’un serveur racine recevant des paquets après qu’ils ont traversé plusieurs réseaux.

Ce principe n’établit pas que l’attaque de 2002 dépendait d’une méthode d’usurpation particulière. Les preuves publiques fournies n’identifient pas la population complète des sources, l’attaquant, le mobile ni la méthode de génération de paquets. Il serait inapproprié d’inférer ces faits de l’existence de normes anti-usurpation.

Le filtrage d’entrée n’est pas non plus un remède propre à un seul réseau contre un flot distribué. Le filtrage des sources falsifiées sur un réseau d’accès n’empêche pas le trafic nuisible d’autres réseaux, ni n’arrête le trafic utilisant des adresses source valides. Son efficacité dépend du déploiement sur les périphéries d’origine pertinentes, d’une politique exacte et de la prise en compte de la complexité légitime du routage.

Le contrôle reste important parce que les défenses côté destination ne peuvent pas réparer chaque faiblesse à la périphérie d’origine. Si le trafic à source falsifiée est autorisé à quitter un réseau d’accès, le service attaqué voit un symptôme après que le point de contrôle le plus discriminant a été dépassé. À l’inverse, un filtrage trop large peut nuire au trafic légitime multi-domicilié. La responsabilité exige des preuves que les contrôles sont à la fois efficaces contre les sources invraisemblables et assez précis pour préserver la connectivité légitime.

Les questions appropriées sont donc bornées:

Un réseau a-t-il déployé des contrôles de validité des sources dans le domaine qu’il pouvait réellement gouverner?
Les exceptions pour le multi-domiciliation et les chemins asymétriques ont-elles été comprises et testées?
Les opérateurs ont-ils collecté des preuves montrant ce que les contrôles acceptaient ou rejetaient?
Les changements de filtrage pouvaient-ils être corrélés à des améliorations du service légitime?
L’atténuation a-t-elle déplacé le trafic nuisible ailleurs ou créé de nouvelles défaillances de joignabilité?

Aucune de ces questions n’identifie l’attaquant de 2002. Aucune n’attribue une responsabilité exclusive aux réseaux d’accès. Elles garantissent que l’analyse ne place pas tout le fardeau sur les serveurs d’autorité lorsque certains contrôles pertinents existent en amont.

La diversité des routes, l’appairage et la capacité de transit appartiennent au même ensemble que le filtrage. Une instance racine peut avoir une capacité de calcul suffisante tout en restant injoignable si son chemin amont est saturé. Une autre instance peut être saine mais recevoir peu de trafic parce que le routage ne dirige pas vers elle les résolveurs touchés. Le filtrage réduit certains risques de trafic; la diversité préserve des chemins de livraison alternatifs; la distribution de service crée des points de capacité supplémentaires. Les contrôles se complètent mais ne sont pas interchangeables.

La coordination est un contrôle opérationnel, pas une centralisation de commandement

Un modèle d’opérateurs distribués dépend de la coordination précisément parce qu’aucune partie ne contrôle l’ensemble du système. Pendant une attaque rapide, les opérateurs ont besoin de termes communs pour décrire ce qu’ils observent, de canaux pour échanger des preuves bornées et d’un moyen de distinguer l’atténuation locale de la restauration à l’échelle du système.

La coordination ne doit pas être confondue avec une permission. Un opérateur racine doit pouvoir protéger son propre service sans attendre qu’une institution centrale dirige chaque action technique. Un réseau de transit doit agir dans son domaine. Un opérateur de résolveur doit préserver le service local. La coordination devient précieuse lorsque ces actions autonomes affectent des résultats partagés.

Les documents de 2002 montrent pourquoi les preuves communes comptent. CAIDA a décrit la performance des chemins depuis des moniteurs nommés. [1] Son analyse ultérieure a décrit les paquets sur des liaisons racine sélectionnées. [2] L’ICANN a résumé les adresses logiques. [5] D-Root a consigné l’événement dans l’historique de l’opérateur. [4] Chaque compte rendu est utile, mais leurs objets différents doivent être réconciliés avec soin.

Les publications ultérieures du SSAC, du RSSAC et des opérateurs peuvent être lues comme des réponses à ce problème de preuves. Elles mettent l’accent sur les contrôles coordonnés, les attentes de service, les mesures partagées et l’atténuation des menaces. [6], [13]-[15] Leur pertinence réside dans l’amélioration de l’observabilité et de la réponse futures. Elles ne doivent pas servir à déclarer que tous ces mécanismes étaient obligatoires ou déployés en octobre 2002.

Une coordination efficace a des résultats mesurables. Les opérateurs peuvent horodater le moment où ils ont reconnu un événement partagé, indiquer quelles identités de service ou instances étaient touchées, enregistrer les changements de routage et de filtrage, identifier les preuves utilisées pour déclarer la reprise et conserver les désaccords sur la portée. Un processus de coordination qui ne produit qu’une étiquette globale — « en service » ou « hors service » — ne saisit pas un système distribué.

La conclusion publique doit rester plus étroite que la certitude interne. Si les opérateurs disposent d’une visibilité incomplète, la déclaration correcte est bornée: le service a récupéré sur des instances et des points d’observation externes précis, tandis que d’autres régions restent non vérifiées. L’incertitude explicite est plus responsable qu’une universalité non étayée.

Un test mesurable de résilience et de restauration

La leçon centrale de l’attaque n’est pas qu’une technologie ultérieure a résolu le risque DNS racine. C’est que les affirmations de résilience doivent être converties en preuves sur l’ensemble du chemin de service.

Un test de responsabilité défendable peut être organisé en sept étapes connectées.

1. Intégrité de l’autorité

La première question est de savoir si les résolveurs disposent d’enregistrements exacts identifiant les identités de service racine attendues. Les informations de la zone racine et du fichier des serveurs racine remplissent cette fonction de registre. Si ces enregistrements sont erronés, la capacité en cours d’exécution à la bonne destination peut ne jamais être atteinte.

L’intégrité de l’autorité est nécessaire mais non suffisante. Réussir cette étape prouve que le système pointe vers les services prévus. Cela ne prouve pas que ces services sont joignables.

2. Joignabilité depuis des réseaux divers

La deuxième étape teste si les adresses logiques peuvent être atteintes depuis plusieurs emplacements réseau indépendants. Les mesures doivent nommer leurs points d’observation, leurs routes lorsqu’elles sont disponibles, leurs métriques et leurs intervalles.

Les observations de CAIDA montrent pourquoi cette discipline compte. Les changements de temps aller-retour signalés étaient des mesures réelles depuis des moniteurs particuliers. [1] Une évaluation moderne de la résilience devrait élargir le nombre et la diversité de ces perspectives, mais doit encore résister à revendiquer plus de géographie que les moniteurs ne couvrent.

Réussir cette étape n’exige pas que chaque sonde rapporte une performance identique. Elle exige que les opérateurs comprennent où le service est sain, dégradé ou non vérifié et évitent de cacher des défaillances régionales dans une moyenne mondiale.

3. Service d’autorité utilisable

La joignabilité doit mener à des réponses d’autorité opportunes et correctes. Une route vers une adresse qui ne renvoie aucune réponse utilisable ne fournit pas de continuité. Les opérateurs doivent distinguer la saturation de liaison, l’épuisement d’instance, les réponses incorrectes et l’atténuation locale qui abandonne le trafic légitime.

La distribution doit être décrite au niveau de l’instance lorsque la divulgation est opérationnellement sûre. Les preuves pertinentes comprennent quels sites de service sont restés disponibles, si la capacité était assez indépendante pour éviter un goulot d’étranglement commun et si les mêmes données d’autorité ont été fournies à travers eux.

La RFC 2870 fournit le contexte antérieur à l’événement pour la capacité, la connectivité diversifiée, la journalisation et la coopération. [8] La RFC 3258 fournit le premier modèle de service distribué avec ses préoccupations de routage et de cohérence. [9] Les documents ultérieurs sur l’anycast et le service racine affinent la comparaison. [10]-[12] Aucun d’eux ne remplace la télémétrie propre à l’attaque.

4. Continuité des résolveurs

La quatrième étape teste si les résolveurs récursifs peuvent continuer à obtenir des réponses grâce au cache, aux nouvelles tentatives et aux identités racine joignables. Cette étape empêche l’évaluation d’assimiler la détresse des serveurs à un échec de transaction.

Les résultats des résolveurs doivent être séparés par état de cache lorsque cela est possible. Un cache chaud montre que le tampon de l’architecture a fonctionné. Une requête exigeant des informations non mises en cache ou expirées teste plus directement la joignabilité d’autorité actuelle. Les deux importent, mais répondent à des questions différentes.

Les RFC 1034 et RFC 1035 fournissent le fondement du comportement de résolveur et de mise en cache qui crée cette frontière. [20], [21] L’état exact du cache de la population mondiale de résolveurs pendant l’événement de 2002 reste inconnu et ne peut pas être reconstruit à partir des seules données de serveurs.

5. Achèvement des transactions légitimes

La cinquième étape mesure si des résolutions réelles ou représentatives orientées utilisateur s’achèvent. Les preuves de transaction doivent nommer le réseau d’accès et la fenêtre temporelle plutôt que de présenter quelques tests réussis comme une preuve globale.

C’est à cette étape que la performance de l’infrastructure devient impact utilisateur. Elle doit encore être interprétée avec prudence. Une transaction peut échouer à cause d’un résolveur local, d’un chemin d’accès, d’une dépendance d’autorité sous la racine ou d’un délai d’attente d’application. L’attribution liée à la racine exige des preuves reliant l’échec à la condition pertinente du service racine.

La conclusion de CAIDA d’un impact opérationnel mondial visible faible est une frontière importante propre à l’événement. [1] Elle ne quantifie pas chaque expérience utilisateur, mais empêche une affirmation d’effondrement universel.

6. Contrôles d’origine du trafic et de routes

La sixième étape teste les contrôles en dehors du service d’autorité. Les réseaux doivent pouvoir expliquer leur posture de validation des adresses source, la capacité des chemins et les changements pertinents de routage ou de filtrage.

Les RFC 2827 et RFC 3704 identifient les principes du filtrage d’entrée et leurs limites opérationnelles. [17], [18] La RFC 4732 place l’atténuation du déni de service dans un contexte d’ingénierie distribué. [19] Les preuves à cette étape ne doivent pas supposer que tout le trafic d’attaque utilisait des sources falsifiées. Elles doivent montrer quels contrôles étaient disponibles, où ils s’appliquaient et si les changements ont préservé le trafic légitime.

La diversité des routes doit aussi être testée plutôt qu’affirmée. Plusieurs noms de fournisseurs amont ne prouvent pas des domaines de défaillance indépendants. Plusieurs routes ne garantissent pas que les résolveurs touchés atteindront une capacité saine. Une évaluation utile relie les observations de route aux résultats de service.

7. Déclaration coordonnée et restauration

La dernière étape demande si les opérateurs peuvent indiquer quand l’événement a été déclaré, quelles frontières de service étaient touchées, ce qui a changé et comment la reprise a été vérifiée.

Le travail de mesure ultérieur du RSSAC offre un cadre pour des preuves comparables du système racine, tandis que les orientations sur l’atténuation des menaces des opérateurs et sur les grands services d’autorité fournissent des points de comparaison supplémentaires. [13]-[16] Ces documents ultérieurs doivent orienter les attentes actuelles sans être présentés à tort comme des obligations rétroactives du jour de l’attaque.

La restauration devrait exiger l’accord entre plusieurs indicateurs:

Les conditions de trafic et de réponse sur les instances touchées se sont stabilisées.
Les routes rendent le service sain joignable depuis divers réseaux externes.
Les réponses d’autorité restent correctes et opportunes.
Les tests de résolveurs réussissent dans des conditions de cache pertinentes.
Les tests de transaction légitime récupèrent.
L’atténuation ne crée pas une défaillance d’accessibilité équivalente.
Les régions ou identités de service encore inconnues sont explicitement consignées.

Aucun indicateur unique ne peut prouver toute la chaîne. Ensemble, ils peuvent soutenir une déclaration bornée et reproductible.

Ce cadre rend la remédiation mesurable. « Ajouter l’anycast », « augmenter la capacité » ou « améliorer la coordination » sont des promesses incomplètes. Une remédiation devrait indiquer quelle frontière de défaillance elle traite et quelles preuves montreront qu’elle a fonctionné. Des instances supplémentaires devraient améliorer la joignabilité ou l’isolation des défaillances. Davantage de capacité devrait augmenter la marge utilisable sur des chemins définis. Le filtrage devrait réduire le trafic nuisible sans exclure les sources légitimes.

La coordination devrait raccourcir la détection, aligner la portée et produire des preuves de restauration comparables.

L’attaque a révélé un problème de continuité, pas un problème de souveraineté

L’événement de 2002 peut être mal compris comme une lutte pour savoir quelle institution contrôlait la racine. Ce cadrage manque la frontière opérationnelle de la défaillance.

Les enregistrements racine identifiaient les services logiques censés répondre. L’attaque n’a pas principalement remis en cause l’existence de ces enregistrements. Elle a mis en cause la capacité des résolveurs à joindre une capacité d’autorité en cours d’exécution à travers le réseau disponible.

Cette distinction compte parce que les enregistrements et le service ont des propriétés de responsabilité différentes. Un enregistrement peut être audité pour son exactitude et ses modifications autorisées. Un service doit être testé pour sa joignabilité, son exactitude, sa capacité et sa continuité. L’institution qui maintient ou coordonne un enregistrement ne contrôle pas automatiquement chaque route et serveur qui le réalise.

L’autonomie pratique des opérateurs de serveurs racine n’est donc pas un obstacle à la responsabilité. C’est un fait que la conception de la responsabilité doit refléter. Chaque opérateur doit pouvoir produire des preuves pour ses propres instances et collaborer à une vue au niveau du système. Les réseaux de transit et d’accès doivent rendre compte de leurs chemins et contrôles de périphérie. Les opérateurs de résolveurs doivent rendre compte de la continuité présentée aux utilisateurs. Les organes de coordination doivent préserver le registre commun sans prétendre commander chaque action opérationnelle.

Cette approche par la réalité est plus stricte qu’un slogan de gouvernance. Elle demande si le système a fonctionné, où il était joignable, quels contrôles ont absorbé l’attaque et comment la reprise a été démontrée. Elle empêche aussi de traiter les enregistrements d’autorité comme des garanties magiques. Un nom correct dans un registre ne déplace pas les paquets.

La même approche contraint les affirmations de prévention. Aucune preuve fournie ne montre qu’un opérateur ou une institution aurait pu empêcher l’attaque à lui seul. Plus de capacité sur une racine n’aurait pas contrôlé le trafic sur les autres racines. Le filtrage sur un réseau d’accès n’aurait pas contraint toutes les sources. La mise en cache des résolveurs n’aurait pas préservé les données indéfiniment. La coordination n’aurait pas créé de capacité par elle-même. La résilience est née de l’effet combiné de plusieurs contrôles.

Le test de responsabilité est par conséquent pluriel mais non vague. Il demande à chaque contrôleur des preuves à la couche qu’il exploite et demande au système dans son ensemble de démontrer la continuité à travers ces couches.

Ce que les preuves publiques ne permettent pas d’établir

Plusieurs faits importants restent inconnus à partir du dossier fourni.

L’identité et le mobile de l’attaquant ne sont pas établis. La population complète des systèmes ou des sources impliqués n’est pas connue. Les preuves ne justifient pas d’attribuer l’attaque à une personne, une organisation ou une classe d’acteur nommée.

Les taux de paquets exacts pour chaque identité racine et instance physique ne sont pas disponibles. Le travail de paquets de CAIDA a couvert les liaisons E, I, K et M en commençant peu après l’attaque et a organisé les observations en intervalles de dix minutes. [2] Ces données ne doivent pas être étendues aux liaisons non surveillées.

Chaque route du jour de l’attaque et chaque changement d’atténuation sont également inconnus. Les preuves publiques ne fournissent pas une reconstruction BGP, d’appairage ou de transit complète pour chaque opérateur racine. Elles ne peuvent pas soutenir des affirmations selon lesquelles une décision de route particulière a causé ou terminé l’événement, sauf documentation indépendante.

La topologie physique complète active le 21 octobre 2002 n’est pas énumérée. L’expansion anycast ultérieure ne peut pas combler cette lacune. Il serait inexact de décrire le modèle de distribution ultérieur comme universellement présent pendant l’attaque.

Les états de cache des résolveurs et les taux exacts de défaillance visibles par les utilisateurs sont indisponibles. La conclusion de CAIDA d’un impact faible est une borne importante, mais pas un recensement de chaque résolveur ou utilisateur. [1] Certaines transactions ont pu échouer; le dossier ne les quantifie pas universellement.

Les chronologies internes complètes des opérateurs, les registres de coordination, les coûts et les allocations juridiques sont également hors du champ des preuves. Les normes techniques et les documents consultatifs ultérieurs identifient des contrôles d’ingénierie, mais n’établissent pas de négligence, d’illégalité, de manquement ou de responsabilité légale. Ces conclusions exigeraient des faits et une analyse juridique non présents ici.

L’efficacité de chaque remédiation après événement ne peut pas non plus être présumée. La comparaison ultérieure de l’ICANN a associé l’impact utilisateur réduit de l’attaque de 2007 en partie au déploiement de l’anycast et à la coordination entre opérateurs après 2002. [5] Cela soutient une comparaison limitée, pas une affirmation universelle selon laquelle chaque contrôle ultérieur a fonctionné aussi bien dans toutes les conditions.

Ces inconnues doivent rester visibles. La précision sur l’incertitude fait partie de la responsabilité de l’infrastructure, car elle empêche qu’une observation locale, un résumé institutionnel ou une amélioration de conception ultérieure soient convertis en une certitude historique non étayée.

La leçon essentielle en matière de responsabilité

L’attaque DNS racine de 2002 était grave parce qu’elle a exercé une pression coordonnée sur l’infrastructure dont les résolveurs récursifs dépendent pour naviguer dans la hiérarchie DNS. Sa signification n’exige pas une affirmation selon laquelle l’Internet a failli s’arrêter ou que chaque utilisateur a perdu le service.

CAIDA a observé une dégradation brutale de performance vers 22 h 00 UTC et a signalé des durées différentes parmi les identités racine surveillées depuis ses points d’observation. [1] Son analyse de paquets ultérieure a documenté le trafic sur des liaisons sélectionnées E, I, K et M. [2] L’historique de D-Root a corroboré la signification opérationnelle de l’événement. [4] L’ICANN a résumé plus tard l’ampleur de l’attaque en indiquant que neuf des 13 adresses logiques de serveurs racine avaient été submergées. [5] CAIDA a néanmoins conclu que l’impact opérationnel mondial visible était faible. [1]

Ces faits s’assemblent lorsque le système est examiné comme une chaîne. Les adresses logiques identifient les services; elles ne sont pas identiques aux déploiements physiques complets. Les routes déterminent quelle capacité un résolveur peut joindre. Les instances d’autorité distribuées créent des alternatives mais dépendent de la topologie et de la cohérence. La mise en cache récursive réduit la dépendance immédiate aux requêtes racine en direct. Les réseaux de transit et d’accès contrôlent des parties du chemin de trafic et de la frontière de validité des sources.

La mesure détermine si les conclusions sont locales, régionales ou à l’échelle du système. La coordination relie les opérateurs autonomes pendant l’atténuation et la restauration.

L’attaque a donc fait de la résilience un test de responsabilité. Elle exigeait plus que la preuve que les enregistrements restaient intacts ou qu’un serveur répondait quelque part. Elle exigeait la preuve qu’un service d’autorité correct restait suffisamment joignable, depuis suffisamment de chemins, pour que la continuité des résolveurs et des transactions soit maintenue.

Les travaux ultérieurs sur l’anycast, la mesure du RSSAC et l’atténuation des menaces peuvent être évalués comme des réponses à ce test. [10]-[16] Ils ne doivent pas être transformés en mythologie du jour de l’attaque ni en obligations légales rétroactives. Leur valeur est de rendre le contrôle et les preuves plus explicites.

Le principe durable est simple: les enregistrements identifient l’autorité; un service en cours d’exécution et joignable prouve la continuité. Un service distribué résilient doit pouvoir montrer les deux. Ses opérateurs doivent démontrer ce qu’ils contrôlaient, ce qu’ils ont observé, comment ils se sont coordonnés et comment ils savaient que la reprise était réelle. Toute autre chose laisse un registre exact pointer vers un service dont la disponibilité ne peut pas être prouvée.

L’attaque DNS racine de 2002 a fait de la résilience d’un service distribué un test de responsabilité

Pourquoi c'est important