Résumé

  • Le projet limite le résolveur à un identifiant de base de données et un identifiant d’incident ; l’application conserve sa propre copie du registre, choisit les opérateurs qu’elle accepte et construit elle-même le lien.
  • La consultation peut révéler l’adresse IP du lecteur et le domaine filtré ; sans relais protecteur, aucun chargement automatique ne doit précéder l’action explicite de l’utilisateur.

Le navigateur affichait seulement un bouton : « Comprendre ce blocage ». L’utilisateur ne l’avait pas encore touché. Pourtant, un service de prévisualisation avait déjà demandé la page d’incident pour vérifier le titre, l’icône et la disponibilité du lien.

La transparence avait précédé le consentement. Elle avait aussi produit une nouvelle trace : cette adresse venait de s’intéresser à ce domaine censuré.

Cette scène donne sa portée réelle à draft-ietf-dnsop-filtering-transparency-00. Le texte propose d’ajouter aux erreurs DNS structurées des références vers des bases publiques décrivant des incidents de filtrage. Mais il refuse de confondre la transmission d’une référence avec l’autorisation de la consulter.

La révision 00, datée du 1er août 2026 et expirant le 2 février 2027, est un Internet-Draft actif du groupe DNSOP, destiné au Standards Track. Ce n’est pas une RFC, un registre IANA déjà établi, une politique de navigateur ni une preuve de déploiement. Son champ fdbs dépend lui-même du projet sur les erreurs DNS structurées. Toute promesse doit donc rester au conditionnel.

Deux identifiants au lieu d’une URL imposée

Une entrée contient db, l’identifiant de l’opérateur d’une base d’incidents, et id, celui d’un incident. Plusieurs entrées peuvent figurer dans la liste fdbs, à condition qu’elles se rapportent au même événement sous-jacent.

Le choix de cette abstraction répond à une menace simple. Le résolveur DNS est souvent configuré automatiquement par le réseau. Si ce résolveur pouvait placer une URL quelconque ou un message libre dans l’interface de l’application, un point d’accès malveillant disposerait d’une surface de hameçonnage.

L’application garde donc une copie locale d’un registre proposé. Pour chaque opérateur, ce registre fournit un modèle d’URI de niveau 1 ou 2. L’application insère l’identifiant de l’incident, obtient une destination possible, puis décide si elle veut la présenter.

Le résolveur choisit les bases qu’il cite. L’application choisit celles qu’elle reconnaît. L’utilisateur choisit éventuellement d’ouvrir. Aucune de ces décisions ne remplace l’autre.

Le clic est une frontière de données

La page d’incident n’est pas une information déjà contenue dans la réponse DNS. Elle nécessite une nouvelle transaction réseau. Celle-ci peut exposer l’adresse du lecteur à l’opérateur de la base, ainsi que le fait qu’un domaine particulier a été recherché puis filtré.

Dans certaines juridictions, ce rapprochement est dangereux. Même un opérateur jugé digne de confiance ne protège pas contre tous les observateurs de chemin. La destination, le moment, le chemin de l’URL ou l’identifiant peuvent suffire à déduire la nature de l’incident.

Le projet permet d’utiliser un mécanisme protecteur tel qu’un relais. En son absence, il impose de ne pas charger automatiquement l’URL avant une action explicite. Ce n’est pas une nuance d’interface. C’est la limite entre proposer une explication et produire une divulgation supplémentaire.

Les architectures modernes comportent plusieurs chargeurs invisibles : aperçus de liens, filtres anti-hameçonnage, tests de réputation, captures de page, préconnexion, résolution anticipée et robots d’entreprise. Chacun peut franchir la limite sans ouvrir d’onglet. Une conformité sérieuse doit les inventorier tous.

Un journal unique nommé « lien affiché » ne suffit pas. Il faut distinguer construction, présentation, activation, choix du relais, requête sortante, redirection et réponse de la base. Sinon, l’organisation ne peut prouver que l’utilisateur a gardé le contrôle.

Un registre local crée son propre temps

Le registre proposé serait indexé par l’identifiant de l’opérateur et contiendrait un nom, un contact et un modèle de résolution. Sa politique serait celle du premier arrivé, premier servi, avec la possibilité pour l’IANA de refuser les inscriptions trompeuses ou fantaisistes.

Une application doit conserver une copie locale et ne pas interroger l’IANA à chaque utilisation. Cette exigence évite un appel central pour chaque incident. Elle signifie aussi que plusieurs vérités opérationnelles coexistent : l’état actuel du registre, la version embarquée, la dernière mise à jour réellement appliquée et la politique de confiance associée.

Un opérateur peut modifier son modèle. Le projet prévient que les applications peuvent mettre longtemps à actualiser leurs copies. Pendant cet intervalle, un identifiant correct peut mener à une ancienne destination ou échouer. L’échec ne prouve pas que l’incident était faux ; il peut révéler une divergence de version.

Le reçu utile associe donc chaque expansion à l’empreinte du registre local. Sans elle, on ne peut reproduire la destination que l’utilisateur a réellement vue.

Être enregistré ne signifie pas être accrédité

Le registre coordonne un espace de noms. Il ne vérifie pas la qualité éditoriale d’une base, son indépendance, son mécanisme de correction, sa compétence juridique, ses délais ou sa politique de conservation.

Le premier arrivé ne devient pas l’arbitre officiel des filtrages. La faculté de refuser une inscription trompeuse ne transforme pas l’IANA en auditeur des incidents. Une application doit donc définir son propre ensemble de confiance, éventuellement avec un choix explicite de l’utilisateur ou de l’organisation.

Cette décision peut tenir compte de l’identité du résolveur, de l’opérateur et de la configuration locale. Elle ne doit pas être cachée derrière un badge « enregistré ». Le registre atteste au mieux qu’un identifiant est associé à un modèle sous une version donnée.

La page accessible ne prouve pas l’incident

Le projet ne fournit pas d’authentification reliant l’expérience de l’application à l’entrée présentée. Un attaquant qui contrôle le résolveur peut prétendre qu’un filtrage a eu lieu alors que ce n’est pas le cas.

Il doit réutiliser une paire db et id conduisant à une ressource existante. Cette contrainte réduit la liberté de l’attaque mais ne la rend pas impossible. Une page vraie peut être citée dans un contexte faux. Un incident réel peut être attribué à la mauvaise requête.

Trois auteurs interviennent : le résolveur affirme la pertinence, le registre indique une route et la base publie un récit. Le succès HTTP confirme seulement que la route mène à une ressource. Il ne lie pas causalement cette ressource à la réponse DNS.

Les libellés publics doivent préserver ces degrés : « signalé par le résolveur », « opérateur reconnu », « page récupérée » et « incident authentifié » ne sont pas synonymes. Le dernier état exige une preuve que le mécanisme ne fournit pas.

L’identifiant peut suivre le lecteur

L’identifiant d’incident peut être partagé entre de nombreuses observations ou être propre à une requête. Cette latitude facilite l’organisation des bases, mais elle ouvre un canal de corrélation.

Un résolveur et un opérateur de base agissant de concert peuvent attribuer un token unique, puis observer lequel est consulté. Une seule organisation peut aussi tenir les deux rôles. L’explication devient alors un lien entre la requête DNS et la navigation ultérieure.

Le relais masque éventuellement l’adresse au serveur final, mais pas nécessairement le token. Il ajoute aussi ses propres journaux. La gouvernance doit suivre la cardinalité des identifiants, leur durée, leur réutilisation et les données conservées par chaque intermédiaire.

Demander à l’utilisateur quels opérateurs il accepte est utile. Ce choix ne certifie pas la non-corrélation. Une base appréciée peut encore émettre des identifiants trop fins ou conserver des accès trop longtemps.

Une réponse conforme peut rester invisible

Certaines applications ne reçoivent pas le détail des réponses DNS de leur système hôte. Le résolveur peut transmettre fdbs, le système peut réduire l’ensemble à une erreur générique et le navigateur ne rien voir.

La chaîne comprend donc l’émission, la livraison, l’exposition par l’hôte, l’analyse, la reconnaissance du registre, l’acceptation par la politique, la présentation et l’action. Mesurer seulement le premier ou le dernier maillon produit une histoire trompeuse.

Un résolveur ne peut pas annoncer que les utilisateurs ont été informés parce qu’il a envoyé le champ. Une base ne peut pas déduire l’absence d’émission de l’absence de visites. Une application ne peut pas considérer sa fonction active si le système d’exploitation ne lui remet jamais les données.

Les taux doivent conserver leur dénominateur à chaque étape. La perte est une information opérationnelle, pas un vide à combler par une estimation optimiste.

Plusieurs références restent plusieurs affirmations

La liste peut contenir des entrées de plusieurs bases pour le même incident. Cela augmente la probabilité qu’une application en reconnaisse une. Cela peut aussi révéler des divergences sur la date, le fondement, le domaine ou l’auteur de la demande.

Le fait que les références partagent un incident déclaré ne les rend pas cohérentes. Le résolveur a choisi la liste ; chaque base maîtrise son contenu ; l’application choisit l’affichage. Une majorité de pages ne produit pas automatiquement la vérité.

L’interface peut présenter le désaccord ou appliquer une priorité locale. Elle ne devrait pas fusionner les textes en un récit sans provenance. La transparence exige de montrer qui affirme quoi.

Une explication qui respecte le refus

La qualité du projet tient à sa séparation des pouvoirs. Le résolveur ne choisit pas une URL arbitraire. Le registre ne commande pas l’affichage. L’application ne transforme pas un identifiant en preuve. L’utilisateur peut refuser la consultation risquée.

Cette architecture disparaît si un produit précharge les pages, accepte tous les opérateurs enregistrés, masque sa version du registre ou présente une page accessible comme une décision authentifiée. La mise en œuvre doit préserver les refus autant que les réussites.

Expliquer un filtrage est légitime. Prouver son origine est une autre fonction. Et demander au lecteur de révéler une seconde fois son intérêt pour le domaine ne doit jamais devenir le prix invisible de la première.

Sources