Résumé

  • Le projet DNS Filtering Transparency transporte deux identifiants — l’opérateur d’une base et l’incident — mais n’authentifie pas le lien entre l’incident vécu et la fiche présentée. Le résolveur conserve la faculté de choisir ce qu’il signale et quand il le fait.
  • L’application prend ensuite sa propre décision : elle garde une copie locale du registre proposé, détermine quels opérateurs elle reconnaît ou juge dignes de confiance, puis choisit d’afficher ou non la référence. Une inscription au registre fournit un gabarit d’URI, pas une validation du récit.
  • Enfin, la consultation peut révéler l’adresse IP de l’utilisateur et son intérêt pour un nom sensible. L’acte explicatif doit donc rester subordonné à une action explicite, avec une trace séparant émission, présentation et consultation.

Pour l’utilisateur, le message pourrait tenir en une ligne : ce nom a été bloqué par le résolveur DNS à la suite d’une demande légale ; davantage d’informations sont disponibles ici. La phrase donne l’impression d’un fait unique, déjà instruit, dont le lien ne serait que la pièce justificative.

Le mécanisme décrit le 1er août 2026 par draft-ietf-dnsop-filtering-transparency-00 est plus prudent. La phrase finale dépend de plusieurs acteurs qui ne disposent ni des mêmes informations ni du même mandat. Le résolveur sélectionne des références. Le logiciel client applique sa propre liste de confiance. L’utilisateur décide s’il souhaite ouvrir une page qui peut ajouter une nouvelle observation à son parcours.

Il ne s’agit pas de trois étapes techniques au service d’un seul verdict. Ce sont trois décisions éditoriales et opérationnelles. Si elles sont fondues dans une mention générique comme « le DNS a expliqué le blocage », personne ne peut ensuite établir où une information a été omise, transformée ou rendue trop risquée à consulter.

Deux identifiants ne font pas une preuve

Le projet ajoute à l’erreur DNS structurée une liste nommée fdbs. Chaque élément contient db, identifiant de l’opérateur d’une base publique d’incidents de filtrage, et id, identifiant d’une fiche particulière. Lorsque plusieurs paires sont envoyées, elles doivent toutes se rapporter au même incident sous-jacent.

Le résolveur ne remet donc pas directement une URL ou un texte libre à l’application. Celle-ci recherche db dans une copie locale d’un registre que l’IANA créerait, récupère un gabarit d’URI de niveau 1 ou 2, puis remplace la variable autorisée par id. Cette indirection réduit la possibilité pour un résolveur rencontré sur un réseau inconnu d’injecter n’importe quelle adresse dans l’interface.

Elle ne prouve toutefois pas que la bonne fiche a été choisie. La section consacrée à la sécurité le dit sans détour : le dispositif n’authentifie pas l’association entre le filtrage constaté par l’application et les informations présentées. Un acteur contrôlant le résolveur pourrait réutiliser une paire valide, menant bien à une page existante, tout en l’accolant à une requête qui n’a rien à voir.

Une page accessible démontre seulement qu’une ressource répond à cette adresse. Elle n’atteste ni la validité d’une injonction, ni la compétence de son auteur, ni l’exhaustivité de la fiche, ni la correspondance exacte entre cible, date, territoire et utilisateur. Le protocole offre un chemin vers un compte rendu. Il ne transforme pas ce compte rendu en constat contradictoire.

Le statut du texte impose la même retenue. La version 00 est un document de travail adopté par DNSOP ; ce n’est pas un RFC et aucun statut RFC visé n’est actuellement indiqué. Parler d’un mécanisme proposé, susceptible d’évoluer, est une exigence de précision et non une réserve de pure forme.

Le résolveur compose la première version

Le premier choix appartient au résolveur. Le projet précise qu’il n’est tenu de transmettre aucune information particulière. Il sélectionne les fournisseurs de bases qu’il prend en charge et décide, selon ses propres mécanismes, dans quels cas et à quel moment joindre une référence.

Le contenu sortant est donc un échantillon décidé, pas l’inventaire naturel de tout ce qui pourrait expliquer la réponse. Un résolveur peut connaître deux bases et n’en citer qu’une ; ne pas savoir rapprocher sa règle interne d’une fiche publique ; appliquer une politique différente selon le type de filtrage ; ou estimer qu’une divulgation supplémentaire contrevient à une autre obligation. Ces hypothèses ne prouvent aucune faute. Elles montrent seulement que la liste est le résultat d’une politique de publication.

L’absence d’entrée fdbs ne signifie donc pas absence de filtrage, d’ordre, de dossier ou de justification. Elle signifie que la réponse reçue ne contenait pas de référence exploitable. La différence est d’autant plus importante que certaines architectures ne donnent pas à l’application accès aux détails de la réponse DNS. Le silence peut se produire avant même que sa politique d’affichage soit sollicitée.

Une trace utile côté résolveur doit conserver l’instant de la requête et de la réponse, la relation de confiance avec le résolveur si elle est établie, le code d’erreur étendu, les paires émises, la règle de sélection et l’existence éventuelle d’alternatives connues mais non publiées. Les noms sensibles n’ont pas vocation à alimenter un journal généraliste. En revanche, l’existence du choix ne doit pas disparaître.

L’application exerce un pouvoir de distribution

Le deuxième filtre est le logiciel qui consomme la réponse : navigateur, système d’exploitation ou autre client. Le projet admet que les applications ne prendront pas en charge le même ensemble d’opérateurs de bases. Il leur demande d’exercer un jugement avant d’afficher un message, en fonction notamment de l’identité du résolveur, de celle de l’opérateur de la base ou de la configuration locale.

Ce pouvoir détermine quel récit institutionnel atteint effectivement l’utilisateur. Deux appareils recevant les mêmes octets DNS peuvent produire deux écrans différents. L’un reconnaît l’identifiant et propose une fiche ; l’autre ne le connaît pas. L’un fait confiance à l’opérateur ; l’autre le masque. L’un peut lire les données DNS de bas niveau ; l’autre n’y a pas accès. Le seul écran final ne permet pas de reconstituer ces bifurcations.

Il faut aussi dater le registre. Le gabarit associé à un identifiant peut être modifié par le contact de la fiche. Le projet demande aux opérateurs de tenir compte de délais potentiellement longs avant que les copies locales soient actualisées. Pour savoir quel lien aurait été construit le jour de l’incident, la valeur actuelle du registre ne suffit pas ; il faut la version consultée par l’application à cet instant.

La procédure d’enregistrement ne résout pas la question de confiance. Le projet propose le principe du premier arrivé, premier servi, tout en permettant à l’IANA de refuser une demande trompeuse ou fantaisiste. Le RFC 8126 rappelle qu’une telle politique n’implique normalement aucun examen substantiel au-delà de la forme et de l’absence de doublon. L’inscription répond à une question de résolution — quel gabarit correspond à quel identifiant — et non à une question de vérité.

La trace applicative doit dès lors nommer la copie du registre et sa date ou son empreinte, le gabarit développé, la version de la liste de confiance, les entrées admises ou écartées, la catégorie de motif et la forme du message présenté. Sinon, une enquête ultérieure confondra facilement une omission du résolveur avec un refus de l’application ou une copie locale périmée.

Consulter l’explication produit une nouvelle donnée

Le troisième choix survient lorsque l’utilisateur suit le lien. Cette requête peut révéler à l’opérateur de la base son adresse IP et le fait qu’une personne à cette adresse a cherché à résoudre un nom filtré. Dans certains contextes, demander pourquoi un nom est bloqué est déjà une information sensible.

Le projet impose donc une séparation nette : en l’absence de mécanisme de protection tel qu’un mandataire, l’application ne doit pas charger automatiquement la fiche sans action explicite de l’utilisateur. Il envisage aussi le cas où résolveur et opérateur de base coopèrent, voire sont la même partie, et utilisent des identifiants uniques pour corréler plusieurs requêtes.

Une bonne interface peut signaler qu’une information complémentaire existe sans la télécharger. Elle peut indiquer qui recevra la requête, proposer un chemin protégé et laisser le choix réel à l’utilisateur. Une bonne preuve de conformité, elle, doit rester sobre : indiquer qu’aucun chargement automatique n’a eu lieu, que l’action a précédé le réseau et quel type de chemin a été utilisé, sans recréer un historique nominatif des domaines sensibles.

La structure n’est pas la confiance

Le mécanisme repose sur le projet plus large Structured Error Data for Filtered DNS. Celui-ci rend certains champs lisibles par une machine et permet de les afficher, journaliser ou traiter. Il interdit cependant de les considérer automatiquement comme fiables, de les montrer sans validation appropriée ou de les laisser influer d’emblée sur une décision de sécurité. Il exige aussi un transport DNS chiffré pour cet échange structuré.

Ces limites forment une règle de gouvernance simple. Structurer une information la rend exploitable ; cela ne la rend pas exacte. Chiffrer le transport protège contre l’observation passive ; cela ne valide pas le récit de l’extrémité. Enregistrer un nom JSON ou un opérateur stabilise une convention ; cela ne délègue pas une autorité de jugement.

Le RFC 7754 complète ce cadre en séparant l’entité qui fixe une politique de celle qui l’applique. Il décrit plusieurs transformations possibles entre loi, règle administrative, politique d’opérateur, architecture et mise en œuvre. Une notification rapide peut aider à corriger les dégâts collatéraux, mais elle ne résout pas à elle seule les questions juridiques ou éthiques, que le RFC laisse hors de son champ.

La fiche de chaîne de divulgation

Daniel Kade propose une fiche compacte composée de trois volets liés. Le volet résolveur conserve le contexte authentifié lorsqu’il existe, la réponse et son erreur étendue, les paires publiées, la règle de sélection et l’état des omissions connues. Le volet application fixe la copie du registre, le gabarit effectivement utilisé, la politique de confiance, la décision de présentation et la catégorie de texte affiché. Le volet utilisateur indique si une consultation a été offerte, si une action explicite l’a précédée, si un mandataire a protégé le trajet et si la récupération a abouti.

Chaque inconnue doit rester une inconnue. Une identité de résolveur non authentifiée ne doit pas être complétée après coup. Une copie ancienne ne doit pas être remplacée par le registre actuel. Une page modifiée ultérieurement ne doit pas être présentée comme le contenu vu alors. Une ordonnance ou une règle indépendante peut être reliée comme une source distincte, jamais déduite du seul couple db et id.

Cette fiche ne légitime pas le filtrage. Elle rend la fabrication de l’avis vérifiable. Elle permet de localiser le point où l’explication s’est perdue, a changé de sens ou a imposé un coût de confidentialité. Surtout, elle empêche un message épuré de prendre l’apparence d’un verdict commun qu’aucun des trois décideurs n’a réellement rendu.

Sources