Résumé

  • La révision 27 de Structured Error Data for Filtered DNS se trouve dans la file du RFC Editor. Elle structure en I-JSON les explications d’un Extended DNS Error, mais elle n’est pas encore un RFC numéroté et ses valeurs finales restent à attribuer.
  • L’authentification d’une connexion DoT, DoH ou DoQ protège le lien entre le client et le résolveur choisi. Elle ne certifie ni l’auteur amont de la politique, ni son fondement, ni l’exactitude du classement, ni la réponse que doit adopter l’application.

Une explication bien formée n’est pas un mandat

La scène d’ouverture est une construction analytique, pas un incident public. Elle met en lumière une confusion fréquente : quand une erreur est proprement structurée, le lecteur lui prête plus volontiers une autorité qu’elle ne possède. La syntaxe peut être impeccable alors que la décision décrite vient d’un fournisseur amont, d’une règle ancienne ou d’un acteur dont le rôle n’a jamais été vérifié.

Le Datatracker de l’IETF indique que draft-ietf-dnsop-structured-dns-error-27, daté du 30 juillet 2026 et mis à jour le 19 août, est dans l’état RFC Ed Queue. Le statut visé est Proposed Standard et le RFC Editor attend l’affectation d’un éditeur. Le texte reste un Internet-Draft. Il contient encore les marqueurs destinés au futur numéro de RFC et aux codes qui seront attribués. Il serait donc faux d’annoncer un code définitif, une prise en charge universelle ou un comportement déjà homogène.

RFC 8914 permet aujourd’hui à un résolveur de joindre un Extended DNS Error à une réponse. Des codes signalent notamment un blocage, un filtrage, une censure ou une réponse forgée. L’EXTRA-TEXT qui les accompagne a toutefois été conçu pour le diagnostic humain. Le nouveau projet autorise le client à envoyer une option SDE EDNS de longueur nulle pour indiquer qu’il sait traiter un objet I-JSON dans ce champ.

L’objet peut porter un contact, une justification lisible, un sous-code numérique géré par registre, un nom d’organisation et une langue. Cette petite grammaire rend l’événement plus facile à localiser, journaliser et expliquer. Elle ne fournit pas la signature d’un décideur. Un nom d’organisation reste une chaîne, une justification reste une affirmation et un sous-code reste l’étiquette choisie par l’émetteur.

Demander le format n’est pas consentir au filtrage

L’option SDE ne contient aucune politique. Elle dit seulement que le client comprend le format structuré. Une règle locale peut décider de ne pas l’envoyer. Sa présence ne vaut ni accord avec le filtre, ni acceptation d’un fournisseur, ni autorisation de contacter automatiquement l’adresse indiquée.

Le serveur conserve la maîtrise de sa réponse filtrée : réponse vide, NXDOMAIN ou, de façon moins souhaitable, adresse forgée. Si le client a annoncé SDE et si le serveur renvoie un EDE lié au filtrage, le projet lui demande normalement de fournir les détails structurés. Il distingue une politique de l’opérateur du réseau d’une politique de l’opérateur DNS et propose un code, encore sans valeur finale, pour un blocage imposé par un serveur DNS amont.

Cette distinction améliore l’attribution technique. Elle ne tranche pas l’attribution institutionnelle. « Politique de l’opérateur réseau » ne dit pas quel contrat s’applique, quelle personne a approuvé la règle, si une décision judiciaire couvre le nom demandé ou si une base de réputation a commis une erreur. Le protocole peut nommer une catégorie sans conférer de pouvoir à celui qui la revendique.

Le sous-code s est lui aussi une information bornée. Parce qu’il est énuméré et enregistré, un logiciel peut le traiter plus sûrement qu’un paragraphe libre. Mais le registre définit la signification du nombre, non la vérité de l’occurrence. Une valeur « logiciel malveillant » ne démontre ni la présence actuelle d’un contenu dangereux, ni la fraîcheur de la source, ni la pertinence d’une interdiction durable.

Le chiffrement sécurise un saut, pas toute la filiation

Le projet interdit d’agir sur l’EXTRA-TEXT reçu sans transport chiffré, car un attaquant sur le chemin pourrait le modifier. Même un canal chiffré ne suffit pas si l’identité du résolveur n’est pas vérifiée : le client doit alors ignorer les champs libres de contact, justification et organisation. Il peut éventuellement considérer le sous-code enregistré, plus étroit.

Une connexion authentifiée DoT, DoH ou DoQ apporte une preuve importante. Elle montre que le client a parlé au résolveur qu’il avait choisi et que les octets n’ont pas été altérés sur ce lien. Elle ne montre pas qu’un serveur amont a produit les mêmes octets, qu’un relais les a conservés ni que l’organisation citée est le véritable principal de la politique.

L’EDE fonctionne saut par saut. Le dernier résolveur peut créer l’explication, la transmettre, en retirer des éléments ou la reformuler. Le projet laisse cette transmission au choix de l’implémentation et de l’opérateur. Le dernier canal peut ainsi être irréprochable tandis que la liaison amont ne l’est pas, ou tandis que le résolveur local recompose un message à partir d’un simple code reçu ailleurs.

Ce n’est pas une faiblesse de TLS, mais une limite de provenance. Les environnements exigeants doivent conserver, hors du paquet, l’identité du résolveur, la configuration de l’amont, le mode de relais, la version de politique, la source de classification, l’horodatage et l’historique des corrections. Sans ces éléments, l’organisation ne sait que ce que son résolveur final a déclaré.

Les anciens relais compliquent encore la preuve. Un proxy qui ne comprend pas EDE peut transporter un texte injecté par un attaquant. Le projet recommande alors de n’accepter ces données que de serveurs DNS explicitement configurés ou d’utiliser les informations sur le résolveur définies par RFC 9606. La relation de confiance vient d’une sélection et d’une vérification opérationnelles, pas du fait que le contenu ressemble à du JSON.

Le canal de recours peut devenir un canal d’attaque

Le champ de contact aide normalement l’utilisateur à signaler une erreur de classement. Un résolveur malveillant peut pourtant y placer une destination contrôlée, se donner le nom d’une institution et pousser l’utilisateur à livrer des données ou à installer un prétendu correctif. La justification libre peut exercer la même pression.

Le projet confie donc une responsabilité décisive à la politique de sécurité du client. Un contact ne devrait apparaître que si le résolveur possède une réputation suffisante selon une configuration administrative ou une liste locale. La justification ne doit jamais alimenter un automatisme qui change l’application de la politique de sécurité ou le comportement DNS. Le nom d’organisation doit rester du texte non cliquable et ne peut être présenté que s’il correspond à une identité de confiance ou passe des contrôles adaptés.

La création et la mise à jour de cette liste de confiance restent hors périmètre. C’est un choix raisonnable. Un registre mondial ne peut pas décider quel employeur, établissement scolaire, foyer, fournisseur d’accès ou organisme public peut contraindre un utilisateur précis. Le responsable local doit documenter cette relation, son renouvellement et sa révocation.

Le client ne doit pas non plus ouvrir automatiquement une connexion à partir d’une URI reçue. La restriction initiale des schémas réduit les appels silencieux, les réflexions et les pièges, sans garantir que le dialogue humain sera honnête. Une interface prudente peut privilégier l’identité vérifiée du résolveur, la description contrôlée du code et un support configuré indépendamment.

Le TTL offre une nouvelle question, pas une correction certaine

Les classements changent. Le projet autorise des TTL courts, parfois dix secondes, afin qu’une réputation corrigée soit réinterrogée rapidement. Des valeurs de trente à soixante secondes peuvent limiter la charge lorsque les changements sont moins fréquents. L’expiration du cache ne prouve toutefois pas que l’amont, les relais et tous les clients ont adopté la correction.

Il faut suivre plusieurs horloges : cache DNS, mise à jour de la source de classement, approbation ou retrait de politique, traitement de la plainte et première observation réussie par les clients. Un TTL de dix secondes ne répare pas une liste actualisée chaque heure ni une procédure d’appel qui dure plusieurs jours.

Une preuve de correction utile associe le nom et le type demandés, l’identité du résolveur, l’EDE et son sous-code, la source amont visible, les TTL, la version du classement, la réception de la plainte, le décideur et le moment où le changement devient observable. Une réponse différente isolée ne démontre pas une convergence générale.

La transparence ne doit pas devenir une fuite. Les champs structurés peuvent révéler l’organisation qui filtre, ses règles et le domaine recherché par l’utilisateur. Le texte interdit leur envoi ou leur journalisation chez des tiers sans que l’utilisateur le sache. Exporter chaque erreur vers une plateforme d’analyse distante peut annuler, après le résolveur, la confidentialité gagnée par le DNS chiffré.

Le message éclaire la décision sans la prendre

Après vérification du résolveur et validation des champs utilisables, l’application conserve plusieurs réponses possibles : afficher une explication limitée, conserver une trace locale, proposer le support interne, attendre le TTL, employer un autre résolveur lorsque cela est autorisé, interrompre une action ou saisir un responsable. Les coûts d’un faux positif et d’un contournement ne sont pas les mêmes dans une entreprise, un foyer ou un équipement critique.

La couche commune doit rester mince : indication de capacité, structure, registres, règles de traitement, exigence de transport et limites de sécurité. Elle ne doit pas transformer une assertion de résolveur en jugement juridique. L’auteur de la politique, le fournisseur de classement, l’opérateur, l’utilisateur et l’autorité publique peuvent partager une preuve sans devenir un seul acteur.

La véritable avancée n’est donc pas de donner au blocage une carte plus élégante. Elle consiste à rendre les responsabilités interrogeables : qui a choisi le résolveur, qui a adopté la politique, qui a fourni le classement, qui peut le corriger et qui porte la conséquence finale. Un format utile rend ces séparations visibles. Un mauvais déploiement leur substitue un voyant vert.

Sources