Interception DNS 2014 en Turquie: routage et responsabilité

Résumé

Du 29 mars au 7 avril 2014, les éléments fournis par Google et RIPE Atlas ont montré que le trafic adressé à des résolveurs DNS publics pouvait atteindre des systèmes de réponse situés à l'intérieur de réseaux turcs plutôt que le service externe attendu. Les observations établissent une interception à des points de mesure donnés, et non une configuration nationale unique et identique.
La responsabilité suit les contrôles qui déterminent le chemin et la réponse effectifs: annonce et installation de route, transfert, identité du résolveur, intégrité de la réponse DNS, mesure indépendante et restauration vérifiée. Les registres, DNSSEC, RPKI et le DNS chiffré ne couvrent chacun qu'une partie de cette chaîne.

Une adresse familière, un service inconnu

Modifier un ordinateur ou un routeur pour utiliser un résolveur DNS récursif public ressemble à un choix direct. L'utilisateur saisit une adresse telle que 8.8.8.8, envoie une requête DNS vers cette adresse et s'attend à ce que le résolveur public de Google la reçoive. En fonctionnement normal, cette attente est utile. Elle ne constitue toutefois pas une preuve de ce que le réseau a fait du paquet. L'adresse exprime la destination souhaitée. L'état du routage et du transfert détermine le système qui reçoit réellement le trafic, tandis que le logiciel de ce système détermine la réponse renvoyée.

Cette distinction est devenue visible sur le plan opérationnel à l'intérieur des réseaux turcs entre le 29 mars et le 7 avril 2014. Les mesures ont montré que le trafic adressé à des adresses IP de résolveurs publics atteignait des systèmes de réponse situés à l'intérieur de l'infrastructure turque plutôt que les services externes attendus. Google a déclaré avoir confirmé des signalements crédibles selon lesquels son service DNS public était intercepté par la plupart des fournisseurs d'accès Internet turcs.

Les mesures de RIPE Atlas ont apporté des observations indépendantes: certaines sondes en Turquie ont connu des changements brusques de latence et ont reçu des réponses associées à l'infrastructure turque. D'autres sondes n'ont pas montré le même comportement.

L'événement importe comme cas de responsabilité des infrastructures réseau, car la configuration du client pouvait rester inchangée alors que l'identité effective du service changeait. Il ne suffisait pas d'inspecter l'adresse du résolveur affichée dans un panneau de configuration. Un compte rendu adéquat devait demander quelle route était annoncée, quelle route était installée, où les paquets étaient transférés, quel résolveur récursif répondait, quelles données DNS il renvoyait, si une validation d'intégrité avait lieu et quand le service attendu avait été rétabli. Ces questions sont liées, mais elles ne sont pas interchangeables.

Le registre public ne justifie pas un récit de mécanisme unique et simple. Les comptes rendus de BGPMon et de l'Internet Society décrivaient des annonces BGP très spécifiques, notamment une annonce /32 pour une adresse de résolveur Google. Les documents présentés à RIPE 68 évoquaient également le routage comme moyen d'interception.

La reconstitution de Stéphane Bortzmeyer ajoutait une réserve importante: un miroir de regard de Turk Telekom ne présentait pas la redirection comme une route BGP ordinaire avec le chemin visible attendu, ce qui suggérait qu'au moins une partie de l'effet pouvait avoir été produite par une route locale statique ou interne. Les observations publiques soutiennent donc une interception à des points de mesure donnés. Elles ne prouvent pas qu'un détournement BGP unique propagé mondialement, une configuration de routage unique ou une politique de réponse unique ait opéré à l'échelle nationale.

Cette incertitude n'est pas une faiblesse à dissimuler. Elle définit le problème de responsabilité. Un incident de routage peut affecter le plan de données même lorsque la route décisive n'est pas visible dans un flux mondial public. Une réponse DNS peut être fausse même lorsqu'un registre IP identifie correctement le détenteur de ressource attendu. Un contrôle d'origine de route peut rejeter une catégorie d'annonce non autorisée tout en manquant une route installée localement. Une réponse DNS signée peut fournir l'intégrité des données pour une zone signée sans authentifier le chemin vers le résolveur récursif.

Le DNS chiffré peut authentifier un canal de transport ultérieur sans garantir que le canal restera joignable. La réponse utile est un modèle de preuves en couches, et non l'affirmation qu'une technologie de sécurité unique aurait rendu l'événement impossible.

L'événement borné: du 29 mars au 7 avril

La chronologie pertinente commence lorsque les mesures issues des réseaux d'accès turcs ont montré un changement dans le traitement du trafic envoyé vers des résolveurs récursifs publics. Le blocage DNS classique peut être contourné lorsqu'un utilisateur choisit un résolveur externe plutôt que le résolveur fourni par un fournisseur d'accès. L'escalade de 2014 en cause ici était différente d'un fournisseur d'accès se contentant de renvoyer une réponse manipulée depuis son propre service DNS annoncé.

Les utilisateurs pouvaient explicitement sélectionner une adresse de résolveur public et voir néanmoins leurs paquets livrés à un autre système de réponse à l'intérieur du réseau d'accès.

La déclaration contemporaine de Google a confirmé ce que l'entreprise disait pouvoir établir au sujet de son propre service: des signalements crédibles indiquaient que les adresses DNS publiques de Google étaient interceptées, et Google attribuait ce comportement à la plupart des FAI turcs. Cette formulation mérite à la fois du poids et de la retenue. C'était la confirmation par un opérateur de service que le trafic destiné à son résolveur ne l'atteignait pas de manière fiable. Ce n'était pas un inventaire publié de chaque système autonome entité, de chaque modification de routeur, de chaque réponse falsifiée ou de chaque abonné touché.

La déclaration ne fournissait pas non plus l'intégralité des journaux internes des opérateurs turcs ni l'identité de la personne ayant autorisé chaque configuration.

RIPE Atlas a fourni une seconde horloge fondée sur la mesure plutôt que sur l'affirmation d'entreprise. Les sondes en Turquie avaient auparavant atteint le résolveur anycast de Google avec un certain profil de latence. Pendant l'événement, certaines ont enregistré une réduction soudaine à moins de dix millisecondes. Un résolveur apparemment atteint aussi rapidement depuis ces réseaux d'accès était incompatible avec le chemin antérieur vers l'instance Google attendue et compatible avec un système de réponse beaucoup plus proche. Des tests DNS ont également renvoyé une adresse associée à l'infrastructure de Turk Telekom pour certaines sondes.

Deux sondes n'ont pas montré le même effet, une observation qui empêche de traiter l'ensemble mesuré comme uniforme.

La fin de l'événement a elle aussi eu plus d'une horloge. Le compte rendu de RIPE a observé que le faux résolveur a cessé de rediriger les requêtes concernant Twitter avant que le faux service 8.8.8.8 lui-même ne disparaisse. Les latences sont revenues à leur profil antérieur dans la soirée du 7 avril. Ces observations séparent au moins trois états: le trafic atteignait encore un résolveur inattendu; la politique du résolveur pour un nom interrogé particulier a changé; et le transfert vers le service public attendu a été rétabli.

Dire simplement que « le blocage a pris fin » pour ces trois états reviendrait à écarter les preuves d'infrastructure.

Le registre borné s'étend donc de la première interception mesurée le 29 mars au retour du comportement de latence attendu le 7 avril. Des restrictions antérieures expliquent pourquoi les utilisateurs ont pu choisir un DNS public, mais elles ne sont pas l'objet de cette analyse. Les épisodes ultérieurs d'interférence DNS, les différends politiques plus larges et les incidents de routage sans rapport sont hors du périmètre.

Maintenir ce périmètre étroit permet d'évaluer les systèmes et les preuves qui contrôlaient la joignabilité du résolveur sans transformer une reconstitution technique en un compte rendu général de la politique Internet turque.

Ce que Google a confirmé — et ce qui restait hors de sa vue

Google exploitait le service attendu, annonçait ses adresses anycast et pouvait observer le trafic arrivant sur ses sites de résolveurs. Il pouvait aussi comparer les signalements d'utilisateurs et les mesures réseau au comportement attendu du service. Sa déclaration constitue par conséquent une preuve solide que l'entreprise ne considérait pas les systèmes de réponse observés en Turquie comme des instances légitimes de Google Public DNS. C'est aussi la base appropriée pour attribuer l'affirmation selon laquelle la plupart des FAI turcs étaient impliqués.

Un opérateur de résolveur externe a pourtant une vue limitée des routes installées à l'intérieur des réseaux d'accès. Si un opérateur introduit une route locale pour 8.8.8.8, les paquets peuvent ne jamais quitter le réseau de cet opérateur et ne jamais atteindre un point de vue visible par Google. Du côté de Google, le symptôme peut être un trafic manquant, une demande géographique modifiée, des signalements de réponses inattendues ou des mesures de tiers. Ces symptômes peuvent établir une défaillance d'identité de service sans révéler la commande, le routeur, l'objet de politique ou la chaîne d'approbation précis qui l'a provoquée.

Cette division de la visibilité importe pour la responsabilité. Google contrôlait le résolveur public attendu, ses annonces légitimes, la surveillance autour de ce service et la communication publique d'incident. Il ne contrôlait pas la table de transfert d'un opérateur d'accès turc. Inversement, un opérateur d'accès pouvait contrôler les routes locales et apprises, la politique de transfert, l'équipement d'interception DNS, les avis aux abonnés et la restauration à l'intérieur de son réseau. Il ne pouvait pas contrôler l'ingénierie anycast de Google ni l'état de signature de chaque domaine interrogé via le résolveur.

Une reconstitution responsable doit attribuer à chaque acteur les preuves que cet acteur était pratiquement en mesure de conserver et de divulguer.

Ce que RIPE Atlas a mesuré

RIPE Atlas transforme des sondes distribuées en points d'observation. Pour cet événement, son importance tient moins au nombre de sondes qu'aux types de faits qu'il pouvait séparer. Une sonde pouvait envoyer du trafic vers l'adresse de résolveur configurée, mesurer le temps aller-retour, émettre des requêtes DNS contrôlées et comparer les données renvoyées. Les mesures prises avant, pendant et après l'incident pouvaient révéler un changement même lorsque le réseau d'accès ne publiait pas sa configuration.

La latence était un signal. Une chute soudaine du délai du chemin antérieur à une valeur inférieure à dix millisecondes ne désignait pas à elle seule le routeur modifié ni ne prouvait une annonce BGP. Elle montrait que l'échange paquet-réponse était devenu beaucoup plus proche en termes de réseau. Dans un service anycast, les chemins peuvent légitimement changer et une instance légitime proche peut réduire la latence. C'est pourquoi la latence seule ne peut pas authentifier un intercepteur.

Dans ce cas, toutefois, le changement de latence était combiné aux preuves de réponse du résolveur et au démenti de Google selon lequel le service nouvellement observé était le sien. La combinaison était matériellement plus forte que l'une ou l'autre observation prise seule.

Les données DNS renvoyées constituaient un autre signal. Le compte rendu de RIPE rapportait des réponses pointant vers l'infrastructure de Turk Telekom pour certains tests. Cette preuve concerne les données émises par le résolveur qui répondait. Elle ne montre pas à elle seule comment la requête y est arrivée. Une route de politique locale, une route d'hôte statique, un protocole de routage interne, une annonce BGP plus spécifique ou un système de redirection de paquets peuvent tous changer le service de réception tout en laissant des traces différentes dans les enregistrements du plan de contrôle.

La réponse aide à identifier qu'une substitution de service a eu lieu; elle n'est pas une trace de route complète.

La variation entre les sondes était tout aussi précieuse. Deux sondes n'ont pas vu le même effet. Elles pouvaient être rattachées à des réseaux différents, soumises à des politiques de routage différentes, positionnées au-delà d'un point d'interception particulier, ou touchées à des moments différents. La preuve figée ne permet pas de déterminer quelle explication s'applique. Elle établit en revanche la règle analytique: un résultat mesuré sur un ensemble de sondes ne peut pas être universalisé à chaque FAI turc, à chaque adresse de résolveur ou à chaque utilisateur.

Les observations négatives ne sont pas un bruit à écarter; ce sont des limites posées à l'affirmation.

Les séries temporelles ajoutaient une troisième forme de preuve. Si la latence chutait brusquement, restait dans le nouvel état puis revenait à la plage antérieure, cette séquence pouvait marquer des changements d'état de transfert. Si la réponse pour un nom donné redevenait normale avant la latence, cela pouvait marquer un changement de politique du résolveur alors que le résolveur inattendu restait sur le chemin. Les temps de restauration différents montrent pourquoi un opérateur doit préserver à la fois l'état de route et les réponses applicatives.

Une réponse DNS propre à un instant donné ne prouve pas que les paquets atteignent à nouveau le résolveur prévu.

RIPE Atlas illustre également les limites de la mesure externe. Une sonde voit depuis son propre point de rattachement et peut enregistrer le délai, les éléments de chemin disponibles et les résultats DNS. Elle ne peut pas exposer la configuration d'un routeur silencieux, un enregistrement de modification privé ou l'identité d'un approbateur. Les mesures établissent des changements étagés de chemin et de réponse à des points de vue turcs observés, avec le retour du profil de latence antérieur le 7 avril. Elles ne reconstituent pas chaque route interne.

Sept faits à ne pas réduire à un « détournement DNS »

L'expression « détournement DNS » est commode, mais elle peut masquer la chaîne de contrôle. Les preuves de 2014 sont plus claires lorsqu'elles sont divisées en sept faits distincts.

Le premier est uneannonce de route. En BGP, un réseau annonce la joignabilité d'un préfixe IP avec des attributs d'origine et de chemin. Les comptes rendus de BGPMon et de l'Internet Society décrivaient des annonces très spécifiques pour des adresses DNS publiques, notamment un /32 pour une adresse de résolveur Google. C'est une preuve concernant un message du plan de contrôle tel que rapporté par ces observateurs. Cela ne prouve pas automatiquement que chaque réseau a accepté l'annonce ni que la même annonce était visible mondialement.

Le deuxième est laroute installée. Un routeur évalue les routes apprises et la politique locale, puis sélectionne des entrées pour son état de routage et de transfert. Une route peut être installée en raison de BGP, d'un protocole de routage interne, d'un routage par politique, d'une entrée statique ou d'un autre mécanisme local. La preuve du miroir de regard de Bortzmeyer importe à cette couche: la représentation BGP ordinaire attendue était absente dans la vue examinée, ce qui soutient la possibilité d'une redirection locale ou statique pour au moins une partie du trafic. Une route installée peut contrôler des paquets sans apparaître comme un nouvel événement d'origine mondiale.

Le troisième est ladestination de transfert. L'état de transfert installé détermine le saut suivant, mais la question opérationnelle est de savoir où le paquet va réellement. Le comportement des équipements, le tunnellisation, le filtrage, les chemins à coût égal et la topologie peuvent produire des résultats qu'un enregistrement de routage de haut niveau n'exprime pas entièrement. Les sondes du plan de données aident à tester cette couche. Un paquet adressé à 8.8.8.8 peut conserver cette adresse de destination tout en étant livré à un système situé à l'intérieur d'un réseau d'accès.

Le quatrième est l'identité du résolveur. Le système qui reçoit le trafic UDP ou TCP sur le port 53 peut se présenter comme un résolveur récursif et répondre aux requêtes, mais la possession du trafic pour une adresse ne prouve pas qu'il s'agit du service attendu par l'utilisateur. Le DNS classique ne fournissait pas de liaison cryptographique de canal entre une requête en clair vers une adresse IP et l'identité opérationnelle de Google. L'anycast ajoute une multiplicité légitime au service, mais un récepteur local non autorisé ne devient pas légitime simplement parce que l'adresse est anycast.

Le cinquième est laréponse DNS. Un résolveur de substitution peut renvoyer une réponse correcte, une réponse manipulée, une erreur, aucune réponse ou des réponses différentes selon les noms. L'observation de RIPE selon laquelle la politique pour les requêtes liées à Twitter a changé avant la disparition du résolveur inattendu montre pourquoi la réponse et l'identité du résolveur doivent être testées séparément. Une réponse correcte provenant du mauvais service ne prouve pas la restauration du chemin prévu. Une réponse fausse prouve un problème de données pour cette requête, pas l'altération de chaque requête.

Le sixième est lavalidation d'intégrité. DNSSEC peut permettre à un validateur d'authentifier des données DNS signées par une chaîne de confiance valide. Il n'identifie pas la route, n'authentifie pas une connexion en clair vers 8.8.8.8, ne signe pas chaque zone et n'oblige pas un intercepteur à assurer la disponibilité. L'état de validation est une observation distincte qui doit être enregistrée pour chaque test.

Le septième est l'impact utilisateur. Un utilisateur peut recevoir une destination différente, une erreur, un délai d'attente ou aucun changement visible, selon le nom interrogé, l'état du cache, le comportement de validation, le réseau et le moment. Les preuves publiques n'énumèrent pas tous les utilisateurs et ne quantifient pas une perte universelle. La substitution mesurée établit une défaillance de contrôle grave parce qu'un service réseau sélectionné pouvait être remplacé de manière invisible, mais elle ne permet pas de produire un chiffre unique de préjudice ni d'affirmer que chaque utilisateur a connu le même résultat.

Ce modèle en sept parties empêche une preuve de faire un travail qu'elle ne peut pas faire. Un collecteur de routes peut enregistrer une annonce sans voir un contournement local de transfert. Un miroir de regard peut montrer une route de plan de contrôle installée sans montrer le chemin exact de chaque paquet. Une réponse DNS peut révéler une manipulation sans nommer la source de la route. Un échec DNSSEC peut détecter des données signées invalides sans identifier l'opérateur qui a redirigé le trafic.

La responsabilité s'améliore lorsque les enregistrements des différentes couches sont corrélés par le temps et par point de vue plutôt que compressés en un slogan.

Les signalements /32 et les éléments de route locale

Un préfixe IPv4 /32 identifie une adresse unique. Annoncer une route aussi spécifique peut être un moyen efficace d'attirer le trafic là où les réseaux l'acceptent, car la correspondance au préfixe le plus long préfère normalement la route la plus spécifique installée. Les descriptions de BGPMon et de l'Internet Society offrent donc un mécanisme plausible d'interception ciblée d'une adresse de résolveur sans détourner un préfixe englobant plus large. Leurs rapports appartiennent à la reconstitution et ne doivent pas être dilués en une vague affirmation selon laquelle « le routage était impliqué ».

Ils ne doivent pas non plus être étendus au-delà de ce que le registre soutient. Une annonce observée par un système de surveillance a une empreinte de propagation déterminée par les politiques d'exportation, d'importation et de filtrage. Certains réseaux rejettent les préfixes plus longs que les limites opérationnelles courantes; d'autres peuvent les accepter ou les conserver dans des contextes limités. L'existence d'un /32 signalé ne prouve pas qu'il a atteint chaque routeur d'accès turc, que chaque routeur l'a sélectionné ou qu'il a causé chaque résultat de RIPE Atlas.

Les éléments de Bortzmeyer pointent vers un chemin différent, potentiellement complémentaire. Dans la vue du miroir de regard de Türk Telekom qu'il a examinée, la redirection n'apparaissait pas comme une route BGP classique avec un chemin AS ordinaire. Sa reconstitution suggérait qu'une route statique locale ou une autre route interne à l'opérateur pouvait expliquer au moins une partie du comportement observé. Une telle route pouvait diriger le trafic d'abonnés vers un résolveur proche tout en restant invisible pour les collecteurs externes. Elle pouvait aussi coexister avec les annonces BGP vues ailleurs.

Les deux ensembles de preuves ne s'excluent pas mutuellement, sauf à insister sur une configuration nationale unique. Une annonce spécifique pouvait toucher un fournisseur ou un domaine de routage tandis qu'un autre fournisseur utilisait un mécanisme local. Un signal BGP public pouvait être présent à un moment pendant qu'une route interne persistait plus longtemps. Des adresses de résolveurs publics différentes pouvaient être traitées différemment. Le registre fourni ici ne tranche pas ces possibilités, de sorte qu'un article exact doit les laisser ouvertes.

Cette distinction modifie l'évaluation du contrôle. Si une annonce d'origine externe non autorisée est la cause, l'autorisation d'origine, la politique d'importation, le filtrage de préfixe et la surveillance des routes sont directement pertinents. Si une route statique configurée localement est la cause, un validateur d'origine de route peut ne jamais l'évaluer. La gouvernance de configuration, les enregistrements de modifications privilégiées, les vérifications de table de transfert et les sondes indépendantes du plan de données deviennent décisives. Si les deux sont présentes, se fier à une seule famille de contrôles laisse un angle mort.

Cela modifie aussi les preuves attendues pendant la restauration. Supprimer une annonce BGP ne prouve pas qu'une route locale a été supprimée. Supprimer une route locale à une extrémité ne prouve pas que chaque région d'accès a convergé. Voir l'origine Google attendue dans un collecteur de routes ne prouve pas que le paquet d'un abonné atteint Google. La restauration exige un ensemble apparié d'observations de plan de contrôle et de plan de données provenant des réseaux qui ont subi l'interception.

Pour cette raison, « détournement BGP » doit être traité comme une description attribuée d'une activité de routage signalée, non comme le mécanisme universel prouvé. « Interception DNS publique » est le terme englobant le plus solide. Il énonce la substitution de service observée tout en laissant la place pour déterminer, opérateur par opérateur, si BGP, le routage interne, le routage statique ou un autre contrôle de transfert l'a produite.

Anycast: adresse stable, instances légitimes multiples

Google Public DNS utilise l'anycast, ce qui permet à la même adresse de service d'être annoncée depuis plusieurs emplacements légitimes. La politique de routage oriente un utilisateur vers une instance joignable. Cette conception peut améliorer la latence et la résilience, mais elle signifie aussi qu'une adresse IP ne correspond pas à un serveur physique fixe ni à une destination géographique immuable.

Un anycast légitime n'efface pas l'identité du service. Les instances multiples sont exploitées comme faisant partie du même service attendu, sous un contrôle de routage et opérationnel autorisé. Un système situé à l'intérieur d'un réseau d'accès sans rapport ne devient pas un résolveur Google simplement parce qu'il reçoit des paquets adressés à 8.8.8.8. La distinction réside dans l'exploitation autorisée, les preuves de routage, le comportement du service et, le cas échéant, le transport authentifié — non dans la familiarité visuelle de l'adresse.

L'anycast rend aussi les tests de latence simplistes insuffisants. Un délai plus faible peut résulter d'un nouveau site légitime, d'un changement de politique de routage ou d'un récepteur proche non autorisé. Pendant l'événement turc, la baisse de latence a pris du sens parce qu'elle coïncidait avec des réponses DNS inattendues et la confirmation de l'interception par Google. Isolément, « plus rapide qu'hier » n'établirait ni un acte répréhensible ni même un dysfonctionnement.

Le registre de responsabilité approprié pour un résolveur anycast inclut donc le préfixe et les origines attendues, les sites ou régions de service qui devraient être joignables depuis les réseaux pertinents, les changements de route dans le temps, les mesures actives et les caractéristiques de réponse. Les transports de résolveur authentifiés modernes peuvent ajouter un signal cryptographique d'identité de service.

Ils ne remplacent toujours pas les preuves de transfert, car un point de terminaison authentifié peut être bloqué et une connexion échouée peut avoir des conséquences importantes pour l'utilisateur même lorsque l'usurpation est empêchée.

Réponses DNS et rôle limité de DNSSEC

DNSSEC est souvent invoqué après un incident impliquant de fausses données DNS. Sa contribution est importante mais plus étroite que la protection de route. DNSSEC signe les données DNS au niveau de la zone et permet à un validateur de construire une chaîne de confiance à partir d'une ancre de confiance établie. Pour un nom signé avec une chaîne intacte, un client validant ou un résolveur récursif validant peut détecter une réponse altérée sans signatures valides.

Cette propriété pouvait faire échouer la validation de certaines réponses falsifiées. Elle n'empêche pas un routeur de sélectionner une route plus spécifique, un réseau d'installer une route d'hôte statique ou un paquet d'atteindre un résolveur récursif inattendu. DNSSEC authentifie les données, pas le chemin vers 8.8.8.8. Cela ne signifie pas non plus que chaque domaine est signé, que chaque client valide indépendamment ou que chaque échec est présenté de manière sûre à l'utilisateur.

L'emplacement de la validation importe. Un résolveur de site typique peut demander à un service récursif d'effectuer la validation puis faire confiance au résultat du service. Si le trafic destiné à ce service récursif est livré de manière transparente à un autre résolveur par un transport DNS non authentifié, l'utilisateur a perdu la frontière de service supposée. Un client validant de manière indépendante peut vérifier lui-même les signatures, mais il peut toujours se voir refuser le service, recevoir des données non signées pour une zone non signée ou être empêché d'obtenir le matériel nécessaire à la validation.

La disponibilité est une propriété distincte. Un intercepteur peut supprimer des paquets, renvoyer des erreurs, bloquer les réponses volumineuses ou faire échouer la validation. Dans ces cas, DNSSEC peut transformer une substitution non détectée en échec de résolution visible, ce qui est précieux, mais il ne maintient pas le service attendu joignable. L'impact pour l'utilisateur peut passer de l'envoi vers une adresse incorrecte à l'impossibilité de résoudre le nom. C'est une amélioration de sécurité sur le plan de l'intégrité, pas la preuve que l'incident réseau a été empêché.

Une évaluation DNS responsable pose donc quatre questions distinctes: le résolveur prévu a-t-il reçu la requête? Le résolveur qui répondait a-t-il renvoyé les données attendues? Les données signées ont-elles été validées correctement? Le service était-il disponible? DNSSEC informe la troisième question et peut influencer la deuxième. Il ne peut pas répondre seul à la première et ne peut pas garantir la quatrième.

Le DNS chiffré est un contexte ultérieur, pas une exigence rétroactive

DNS over TLS et DNS over HTTPS ont été normalisés après l'événement de 2014. Ils doivent servir à expliquer les contrôles disponibles aujourd'hui pour l'identité du résolveur et la confidentialité, non à réécrire la référence historique ni à laisser entendre que les réseaux turcs n'ont pas déployé des normes qui n'existaient pas encore sous leur forme ultérieure.

Les deux approches peuvent protéger les requêtes dans un canal chiffré authentifié. Si un client est configuré pour authentifier le point de terminaison du résolveur prévu et valide correctement le certificat, un système de substitution dépourvu des justificatifs requis ne devrait pas pouvoir usurper ce point de terminaison avec succès. Cela ajoute une propriété d'identité de service que le DNS classique en clair vers une adresse IP ne fournissait pas.

La protection reste conditionnelle. La résolution d'amorçage, la validation de certificat, la configuration du point de terminaison, le comportement de repli, la politique d'entreprise et l'implémentation client façonnent tous le résultat. Un réseau peut bloquer le transport chiffré, le limiter, réinitialiser les connexions ou rendre le point de terminaison injoignable. Un client qui bascule silencieusement vers un DNS non authentifié peut réintroduire le problème de confiance initial. Un client qui échoue de manière fermée préserve l'identité mais peut perdre la résolution de noms.

Le DNS chiffré n'authentifie pas non plus BGP et ne prouve pas qu'une route est légitime. Il peut révéler la conséquence pratique d'un mauvais routage lorsque le canal authentifié échoue, et il peut empêcher un système sur le chemin de lire ou de substituer des messages applicatifs réussis sous l'identité attendue. La surveillance des routes et la mesure du plan de données restent nécessaires pour établir pourquoi le point de terminaison est devenu injoignable et où les paquets sont allés.

La validation de l'origine de route et l'angle mort du routage local

Les registres de ressources et les systèmes d'autorisation de route fournissent des preuves essentielles sur qui est habilité à annoncer un espace d'adressage. Ce sont des enregistrements de responsabilité: ils permettent aux opérateurs et aux observateurs de comparer une annonce BGP à une origine autorisée. Ils ne poussent pas la configuration dans chaque routeur, n'imposent pas chaque décision d'importation et n'empêchent pas un contournement local de transfert.

La validation d'origine de route, telle que décrite dans le modèle de l'IETF, classe une route BGP reçue en comparant son origine et sa longueur de préfixe aux autorisations d'origine de route. Une origine falsifiée pour un préfixe Google couvert pouvait être classée comme invalide là où des données d'autorisation appropriées existaient et étaient disponibles. Un opérateur appliquant une politique de rejet pouvait alors refuser cette route. Ces conditions comptent. La couverture d'autorisation, les réglages de longueur maximale, la disponibilité du validateur, la politique du routeur et le traitement opérationnel déterminent le résultat.

La validation d'origine n'est pas une validation complète du chemin. Une route conservant une origine autorisée mais empruntant un chemin inattendu est hors de sa décision centrale. Plus important pour les preuves turques, une route statique insérée à l'intérieur d'un réseau d'accès peut ne pas être du tout une route BGP reçue. Elle peut rediriger le trafic d'abonnés sans créer d'événement d'origine qu'un validateur pourrait classer. Une route interne ou une règle de transfert par politique peut créer un angle mort de visibilité similaire.

C'est pourquoi les signalements /32 et la réserve de Bortzmeyer exigent des contrôles en couches. À la frontière interdomaine, les opérateurs peuvent maintenir des politiques d'importation explicites, filtrer les routes plus spécifiques invraisemblables, surveiller les changements d'origine et de chemin, et comparer les annonces observées aux données de registre et d'autorisation. À l'intérieur du réseau, ils peuvent contrôler les changements de route privilégiés, journaliser les routes statiques et de politique, examiner les entrées de transfert et tester les destinations externes connues depuis des points orientés abonnés.

La mesure indépendante peut détecter une divergence lorsque les deux environnements de contrôle échouent ou lorsque les enregistrements sont incomplets.

Les orientations du NIST sur l'échange de trafic interdomaine résilient soutiennent de même une défense bâtie à partir de la sécurité de route, de la surveillance, de la réponse et de la continuité plutôt que d'un commutateur unique. La surveillance doit inclure des alertes sur les annonces plus spécifiques inattendues et les changements touchant des adresses d'infrastructure publique critiques. Pourtant, les collecteurs publics seuls ne peuvent pas voir chaque décision interne.

Les opérateurs ont besoin de télémétrie locale, et les parties externes ont besoin de tests du plan de données qui ne supposent pas que le plan de contrôle raconte toute l'histoire.

Le filtrage exige aussi de la précision. Une règle générale sur les /32 n'est pas une leçon d'incident adéquate. L'exigence pertinente est qu'un opérateur documente ce qu'il accepte, pourquoi des exceptions existent et comment le transfert réel vers une destination critique est vérifié. Le filtrage peut réduire le risque tout en laissant la configuration locale et la substitution de service non testées.

L'exactitude des registres reste nécessaire même si elle n'est pas une exécution. Les enquêteurs ont besoin d'enregistrements fiables de préfixe, d'ASN, de contact et d'autorisation pour identifier le détenteur de ressource attendu, comparer les origines, informer les équipes responsables et reconstituer un événement de route. Des enregistrements inexacts ralentissent la réponse et brouillent la responsabilité. Des enregistrements exacts ne peuvent toutefois pas obliger les paquets à leur obéir. L'état de route et de transfert en cours doit être observé.

L'affirmation appropriée est donc modeste et opérationnelle. La validation d'origine fondée sur RPKI pourrait traiter certains scénarios d'origine BGP non autorisée dans les bonnes conditions d'autorisation et de politique. Elle ne détecterait ni n'empêcherait nécessairement une interception locale ou statique, un problème de chemin à origine autorisée, une manipulation de réponse DNS ou un blocage de transport. Sa valeur est celle d'un contrôle limité dans une chaîne de preuves.

La responsabilité suit le contrôle pratique

La responsabilité devient plus claire lorsqu'elle suit les systèmes que chaque acteur pouvait exploiter, inspecter et restaurer.

Les opérateurs d'accèscontrôlaient le routage et la politique de transfert orientés abonnés. Ils étaient en mesure de savoir si les routes vers les adresses de résolveurs publics étaient apprises de l'extérieur, injectées en interne, configurées statiquement ou redirigées par un autre équipement. Ils pouvaient préserver l'historique de configuration des routeurs, les journaux de sélection de route, les entrées de transfert, les horloges des équipements, les tickets de changement et les emplacements des résolveurs de substitution. Ils contrôlaient aussi la communication client et l'acte de suppression de l'interception locale. Lorsqu'un opérateur acceptait une annonce externe, il contrôlait sa propre décision d'importation même s'il n'était pas à l'origine de la route.

Les opérateurs de transit et d'interconnexioncontrôlaient la propagation sur leurs sessions et pouvaient observer les annonces qui traversaient leurs frontières. Leurs preuves pertinentes incluaient les routes reçues et annoncées, les décisions de filtrage, les changements de session et les notifications. Ils pouvaient limiter la portée d'une annonce interdomaine non autorisée. Ils ne pouvaient pas nécessairement détecter une route statique restée à l'intérieur d'un réseau d'accès aval, de sorte que leurs enregistrements propres ne réfutaient pas une interception locale.

L'opérateur du résolveur attendu, Google dans l'exemple central, contrôlait les annonces anycast légitimes, les instances de résolveur, la télémétrie du service, la surveillance externe et la divulgation d'incident. Google pouvait dire si un système de réponse nouvellement observé appartenait à son service et pouvait tester la joignabilité depuis les points de vue disponibles. Il ne pouvait pas supprimer directement une route installée chez un autre opérateur ni produire des enregistrements de configuration privés qu'il ne possédait pas.

Les organisations de mesure et les chercheurs réseaucontrôlaient les sondes indépendantes, les méthodes de collecte, les horodatages, l'analyse et la publication des limites. RIPE Atlas pouvait montrer que le comportement de chemin et de réponse changeait à des points de vue donnés. La surveillance BGP pouvait enregistrer les annonces visibles par ses collecteurs. L'analyse des miroirs de regard pouvait tester ce qu'un opérateur exposait depuis des routeurs sélectionnés. Chaque système avait une frontière de visibilité, et un rapport responsable exigeait de garder cette frontière attachée au constat.

Les opérateurs de domainecontrôlaient si leurs zones étaient signées et si le matériel DNSSEC était correctement maintenu. Leurs décisions conditionnaient la possibilité pour un validateur fonctionnel de rejeter cryptographiquement des données falsifiées pour leurs noms. Ils ne contrôlaient pas la route vers le résolveur récursif d'un utilisateur. Signer une zone ne pouvait pas rétablir la joignabilité du résolveur ni empêcher un réseau d'accès de supprimer des requêtes.

Les éditeurs de logiciels et de matérielcontrôlaient la validation client, l'authentification du transport, le comportement de repli, la présentation des erreurs et l'observabilité. En 2014, le comportement courant des résolveurs en clair offrait peu de preuve directe que le service public configuré avait répondu.Les utilisateurs et les administrateurs réseaupouvaient choisir une adresse de résolveur et parfois lancer des tests, mais ils ne pouvaient généralement pas inspecter une route cachée ni forcer un fournisseur à honorer la destination prévue. Le choix de configuration n'était pas le contrôle de l'infrastructure.

Les autorités publiques ou d'autres instances dirigeantesne seraient pertinentes que dans la mesure où des preuves attribuées établiraient une instruction, une base juridique ou un rôle opérationnel. Les documents bornés pour cet article ne fournissent pas de registre juridique privé complet ni de chaîne de décision. Les preuves techniques peuvent identifier les points de contrôle de route et de résolveur sans convertir ces observations en conclusions sur un ordre non observé ou une intention individuelle.

Cette cartographie évite deux erreurs symétriques. Elle ne fait pas d'un registre ou d'un opérateur de résolveur le souverain des routes à l'intérieur d'un autre réseau. Elle ne permet pas non plus à un opérateur d'accès de traiter une adresse de destination familière comme la preuve qu'il a transféré le trafic vers le service attendu. Chaque acteur est responsable des preuves et des contrôles à sa portée pratique, et les incidents transfrontaliers exigent que ces enregistrements soient joints.

Un test de restauration et de récurrence préservant les preuves

La restauration doit être démontrée, et non déduite d'une réponse d'apparence normale. Les mesures turques suggèrent une séquence qu'un futur processus d'incident peut rendre explicite.

La première étape est de figer la chronologie. Les opérateurs et les observateurs indépendants doivent synchroniser les horodatages et préserver les mises à jour BGP, les informations de routage local, les entrées de transfert, les changements de configuration, les journaux de résolveur, les captures de paquets lorsque c'est légal et proportionné, les résultats de sondes et les communications d'incident. Le registre doit distinguer le moment où une annonce est apparue, où une route a été sélectionnée, où le trafic d'abonnés a changé de destination, où les réponses ont changé et où le service attendu est redevenu joignable.

La deuxième étape est d'identifier la portée de la route. Les collecteurs de routes publics peuvent tester si une origine inattendue ou une annonce plus spécifique était visible de l'extérieur. Les enregistrements de voisins peuvent montrer quelles sessions l'ont reçue ou exportée. Les vues locales des opérateurs peuvent révéler des routes internes et statiques que les flux publics manquent. Une vérification de table de transfert sur les équipements orientés abonnés peut établir quel saut suivant contrôle réellement le paquet. Aucune vue ne doit être acceptée comme substitut des autres.

La troisième étape est de tester le plan de données depuis plusieurs réseaux pertinents. Les sondes doivent mesurer la latence, le chemin, la perte de paquets et la joignabilité vers chaque adresse de résolveur impliquée dans l'événement. Les résultats ont besoin du réseau de la sonde et du contexte de localisation, car deux sondes turques en 2014 ne correspondaient pas au profil touché. Un ensemble diversifié de points de vue peut révéler si la restauration est nationale, propre à un fournisseur, régionale ou partielle. Elle ne doit pas être décrite comme universelle au-delà de l'ensemble mesuré.

La quatrième étape est d'identifier le service qui répond. Des requêtes DNS contrôlées peuvent comparer les codes de réponse, les enregistrements, les valeurs de durée de vie, le comportement de récursion, le traitement DNSSEC et d'autres caractéristiques stables du service. Un point de terminaison de résolveur authentifié moderne peut fournir une preuve d'identité plus forte lorsqu'il est configuré. Les enquêteurs doivent être prudents avec les empreintes: un comportement logiciel similaire n'est pas une propriété concluante, et une réponse correcte n'établit pas le résolveur prévu.

La cinquième étape est de séparer la restauration de la réponse de la restauration du chemin. Les tests doivent inclure des noms précédemment touchés, des noms signés, des noms non signés, des cas de test DNSSEC délibérément invalides et des contrôles neutres. Si des réponses choisies redeviennent normales alors que la latence et l'identité du service restent anormales, l'état d'interception n'est pas entièrement clos. La séquence de 2014 — la politique de réponse changeant avant la disparition du faux résolveur — montre pourquoi cette condition importe.

La sixième étape est de vérifier les protections de routage selon le mécanisme constaté. Pour un événement d'origine externe, cela peut inclure les données d'autorisation, l'état de validation d'origine, les décisions d'importation, la politique de plus-spécifiques, les alertes de surveillance et le retrait de propagation. Pour une route locale ou statique, cela peut inclure la suppression de configuration, l'examen des changements privilégiés, l'inspection des routes internes, les vérifications de transfert équipement par équipement et la confirmation qu'aucune politique équivalente ne demeure ailleurs.

Si le mécanisme reste inconnu, les deux branches exigent des tests.

La septième étape est de tester la continuité en cas de défaillance. La validation DNSSEC doit être observée plutôt que supposée. Le DNS chiffré authentifié, là où il est utilisé aujourd'hui, doit être testé pour la validation correcte du point de terminaison et le comportement explicite lorsque le point de terminaison ne peut pas être atteint. Les opérateurs doivent vérifier que le repli ne remplace pas silencieusement un résolveur authentifié par un résolveur non authentifié contrairement à la politique. Ces vérifications ne garantissent pas la disponibilité; elles rendent le mode de défaillance visible et borné.

La huitième étape est la confirmation indépendante. Les tableaux de bord des opérateurs, les sondes externes, l'opérateur du résolveur attendu et les moniteurs de route doivent confirmer conjointement la route, l'identité du point de terminaison, les réponses et la portée touchée. Un enregistrement de clôture doit identifier les adresses de résolveur et les réseaux testés, la source de la route, toute annonce externe ou route locale, le système de réponse, les résultats de validation et de transport, le moment de restauration de chaque couche et les inconnues restantes.

Le résultat doit être conservé assez longtemps pour tester la récurrence plutôt que déclaré complet après un seul échantillon réussi.

Inconnues, limites juridiques et discipline d'attribution

Plusieurs faits importants restent hors du registre public borné ici. La configuration exacte de chaque FAI est inconnue. L'ensemble complet des chemins BGP, routes internes, entrées statiques, équipements de transfert et adresses de résolveurs touchées est indisponible. La répartition entre les mécanismes signalés par les observateurs BGP et la possibilité de routage local identifiée par Bortzmeyer ne peut pas être quantifiée à partir de ces documents.

Le registre n'énumère pas non plus chaque utilisateur touché, chaque réponse de domaine altérée ni la perte économique. Il ne contient pas tous les journaux privés, instructions internes, approbations de changement, documents juridiques ou tests de remédiation. Il ne peut pas établir qui a pris chaque décision ni si chaque réseau a agi sous la même direction. Ces lacunes doivent rester des lacunes plutôt que d'être comblées par des inférences.

« Interception » dans cet article décrit le comportement réseau mesuré: des paquets adressés à un résolveur public attendu atteignaient un autre système de réponse. Ce n'est pas un constat d'intention criminelle, de négligence, de surveillance, de responsabilité ou de violation légale particulière. Le registre technique peut soutenir des questions pour les opérateurs et les décideurs, mais les conclusions juridiques exigent des preuves et un droit qui dépassent cette reconstitution.

L'attribution importe tout autant pour les affirmations positives. La déclaration de Google sur « la plupart des FAI turcs » appartient à Google. La description du /32 appartient aux rapports de BGPMon et de l'Internet Society. Les observations de latence, de réponse, de variation entre sondes et de restauration appartiennent à RIPE Atlas. La réserve sur la route locale ou statique appartient à la reconstitution de Bortzmeyer. Garder ces étiquettes attachées empêche un compte rendu secondaire d'acquérir plus de certitude que ses preuves sous-jacentes.

Le routage des résolveurs comme test de responsabilité

L'interception DNS publique de 2014 en Turquie a exposé un écart entre l'identité configurée et la réalité opérationnelle. Un utilisateur pouvait conserver 8.8.8.8 dans un panneau de configuration pendant que le réseau d'accès livrait le paquet à un autre résolveur récursif. Aucun enregistrement unique ne ferme cet écart.

Les signalements d'un /32 ne prouvent pas un mécanisme universel; un miroir de regard peut manquer l'état de transfert; RIPE Atlas peut montrer une substitution mais pas l'approbateur interne; DNSSEC n'authentifie pas une route; la validation d'origine peut manquer une route statique locale; et le DNS chiffré authentifié ne peut pas garantir la joignabilité.

La norme pratique est en couches et menée par les preuves. Les enregistrements de ressources et d'autorisation identifient le contrôle attendu. La télémétrie de routage montre les chemins annoncés et sélectionnés. Les sondes de transfert montrent où vont les paquets. Les tests de résolveur montrent quel service répond et ce qu'il renvoie. La validation et le transport authentifié testent l'intégrité et l'identité dans leurs limites. Des mesures horodatées et indépendantes montrent la restauration et la récurrence.

Cette norme n'exige pas d'affirmer que chaque réseau turc a utilisé la même méthode ni que chaque utilisateur a subi le même préjudice. Elle exige quelque chose de plus durable: chaque acteur disposant d'un contrôle pratique doit pouvoir montrer ce que son infrastructure a fait, quand elle a changé, comment le service public sélectionné a été déplacé et comment le chemin et le service attendus ont été restaurés. Dans un réseau routé, l'adresse qu'un utilisateur choisit est une demande. La responsabilité commence par la preuve de la manière dont le réseau en fonctionnement l'a honorée — ou remplacée.

L'interception DNS publique de 2014 en Turquie a fait du routage des résolveurs un test de responsabilité