Résumé

  • Le projet d’option ECS permet à un client d’autoriser un résolveur récursif à transmettre une partie de son adresse et d’en fixer la longueur maximale, sans connaître l’adresse publique vue derrière un NAT ou un VPN.
  • La règle décisive porte sur la garde des données : une réponse obtenue avec ECS ne doit pas être servie à un client non signalant, car aucune marque dans la réponse ne révèle qu’elle a été adaptée.

Le résolveur possède une réponse en cache. Elle est fraîche, valide et correspond au nom demandé. Son défaut n’apparaît dans aucun champ de la réponse : elle a été obtenue à l’aide d’EDNS Client Subnet pour un client qui avait accepté cette divulgation. Le nouveau demandeur, lui, n’a rien accepté.

S’il reçoit cette entrée, le résolveur n’a transmis aucun préfixe supplémentaire au moment de la seconde requête. Il a pourtant fait franchir au résultat d’une divulgation antérieure une frontière de consentement. Le paquet livré au client ne dit pas « réponse adaptée ». L’historique qui permettrait de comprendre le choix reste dans l’infrastructure du résolveur, ou disparaît.

C’est ici que la première version de Client Opt-In Signaling for EDNS Client Subnet devient plus intéressante qu’un simple nouveau champ EDNS. Daté du 20 août 2026 et expirant le 21 février 2027, le texte est un Internet-Draft individuel, pas un document adopté par le groupe DNSOP ni une RFC. Il affiche une intention expérimentale et demande un code encore marqué TBD. Il ne prouve aucune mise en œuvre. Il formule néanmoins une règle d’architecture nette : le consentement doit accompagner la garde et la réutilisation des données, pas seulement la requête qui les a produites.

La configuration du résolveur n’est pas le choix du client

RFC 7871 permet à un résolveur récursif d’envoyer aux serveurs faisant autorité un préfixe de l’adresse réseau du client. Le serveur peut alors adapter sa réponse à ce préfixe. Dans le modèle existant, un résolveur configuré pour ECS peut transmettre cette information même si le client ne fournit aucune option ECS. Le client peut se retirer en envoyant une longueur de préfixe source égale à zéro.

Ce retrait ne résout pas toutes les demandes intermédiaires. Pour demander un préfixe non nul plus court avec l’option ECS existante, le client doit fournir l’adresse dont proviennent les bits. Derrière un NAT, un NAT opérateur ou un VPN, il peut ignorer l’adresse publique observée par le résolveur. L’adresse privée locale n’est pas un substitut approprié.

Le projet sépare donc deux décisions. La nouvelle option donne la permission de transmettre et peut fixer un plafond. L’option ECS ordinaire, lorsqu’elle est présente, fournit une adresse et son propre plafond. Si le client ne fournit pas d’adresse exploitable, le résolveur peut choisir l’adresse source qu’il observe. La longueur effective devient le minimum entre le plafond du client, celui d’ECS, la politique locale du résolveur et la taille maximale de la famille d’adresses.

Cette séparation empêche de confondre l’objet technique avec le mandat. Voir une option ECS ne signifie pas que l’utilisateur final l’a demandée : un résolveur de transfert peut l’ajouter pour les clients qu’il dessert. La nouvelle option sert précisément à exprimer un choix reçu directement.

Une absence vaut plus qu’un opt-in vague

Le projet prévoit deux formes de requête. Avec un octet, le client fixe le nombre maximal de bits transmissibles. Sans donnée, il autorise la transmission mais laisse le maximum à la politique du résolveur. Cette forme de longueur zéro n’est donc pas une minimisation stricte ; elle délègue le réglage.

Le client qui n’autorise aucune transmission devrait omettre l’option. Il peut aussi envoyer la valeur explicite zéro, mais cette valeur révèle sur un transport non chiffré qu’il met en œuvre le mécanisme. L’omission devient ainsi un acte de contrôle : pour un résolveur conforme au projet, elle signifie qu’aucune information d’adresse du client ne doit partir.

Cette affirmation demeure conditionnelle. Un résolveur ancien ignore une option EDNS inconnue et répond comme auparavant. Une réponse DNS ordinaire ne démontre donc pas que l’absence ou le plafond a été compris. Le mécanisme protège le comportement d’un résolveur qui l’implémente ; il ne transforme pas un service non compatible en service conforme.

La réponse est une déclaration, pas une attestation

Un résolveur qui accepte l’option renvoie la longueur effective. Le client peut distinguer une valeur zéro d’un plafond positif et, dans certains cas, détecter l’absence de prise en charge. Mais le champ est une déclaration du résolveur sur sa propre conduite.

Les enregistrements OPT ne sont pas signés par DNSSEC. Le chiffrement du transport protège le message contre la modification entre le client et le résolveur, mais il ne rend pas la déclaration exacte. Un résolveur compromis peut envoyer davantage de bits en amont et en annoncer moins en aval. Pour vérifier la divulgation réelle, il faut observer ce que les serveurs faisant autorité reçoivent.

Cette distinction doit rester visible dans les tableaux de bord. La requête prouve le choix du client. La session chiffrée prouve une protection de transport et l’identité de l’extrémité selon le mécanisme utilisé. La valeur renvoyée prouve ce que le résolveur affirme. Une mesure du côté faisant autorité prouve le préfixe observé à cet endroit. Aucune de ces preuves ne remplace les autres.

Le signal ne devient pas un passeport

Le projet interdit au résolveur de copier l’option d’opt-in dans une requête envoyée en amont ou à un serveur faisant autorité. EDNS fonctionne de proche en proche. L’instruction vise le résolveur récursif qui reçoit directement le choix du client ; elle n’est pas un titre transférable donnant à toute une chaîne le droit de parler au nom de l’utilisateur.

Un résolveur de transfert devient lui-même le client du résolveur suivant. Il peut émettre sa propre option en amont, mais ne doit jamais augmenter le plafond reçu. S’il construit lui-même l’option ECS, il peut rendre compte du nombre de bits du client transmis. S’il laisse le résolveur amont choisir l’adresse, celui-ci voit l’adresse du transfert, pas celle du client initial ; la valeur à déclarer pour les bits du client est alors zéro.

Cette non-transitivité impose une responsabilité locale. Chaque intermédiaire peut prendre une décision qu’il contrôle, sous la contrainte reçue, mais aucun ne peut inventer une autorisation globale. Le modèle rejoint une discipline plus large de l’infrastructure Internet : coordonner le minimum nécessaire et conserver la preuve à l’endroit où la décision a réellement été prise.

La provenance du cache est une obligation fonctionnelle

Le projet exige qu’un résolveur sache, pour chaque entrée, si elle a été obtenue au moyen d’ECS. Une entrée ECS ne doit pas répondre à un client qui n’a pas envoyé le signal. Isoler les caches des clients signalants et non signalants est une solution possible ; attacher une provenance et appliquer des règles d’éligibilité en est une autre.

La raison n’est pas purement sémantique. RFC 7871 prévoit des recherches par plus long préfixe. Sans exclusion, une requête dépourvue d’ECS pourrait correspondre à l’adresse observée du client et récupérer une réponse adaptée à un réseau antérieur. L’absence d’un indicateur dans la réponse rendrait la violation invisible pour le destinataire.

Pour un client signalant, les règles ordinaires de correspondance continuent. Une entrée acquise avec un préfixe plus long que le plafond actuel peut être servie, car la lecture du cache ne transmet pas de nouveaux bits. Le plafond régit la divulgation en amont ; il ne rend pas automatiquement inutilisable toute donnée acquise dans un autre contexte autorisé. Il faut donc conserver deux dimensions : la provenance de l’entrée et l’éligibilité du demandeur.

Cette nuance évite deux erreurs contraires. La première consiste à réutiliser une réponse adaptée sans consentement. La seconde consiste à prétendre qu’une réponse depuis le cache divulgue à nouveau le préfixe initial. La gouvernance précise les actes réels au lieu de choisir une métaphore générale.

Le plafond n’est pas l’usage effectif

Dans la version 00, la réponse annonce la longueur effective calculée pour la requête, même si la réponse provient du cache. Cette longueur est un plafond de politique. Elle peut être positive alors qu’aucun paquet ECS n’a été envoyé en amont pour cette requête.

Le texte conserve comme question ouverte la possibilité de rapporter plutôt le nombre de bits réellement utilisés, notamment lors d’un accès au cache. Le choix modifierait le sens du reçu. « Le résolveur pouvait transmettre au plus 24 bits » et « 24 bits ont servi à obtenir cette réponse » ne sont pas la même proposition. Un système de contrôle qui stocke un seul nombre sans sa sémantique fabrique une certitude artificielle.

Le même principe vaut pour le registre. Le code de l’option reste TBD. Une attribution future par expertise faciliterait l’interopérabilité, mais ne certifierait ni la séparation des caches, ni l’honnêteté des rapports, ni le respect des plafonds dans une chaîne de transfert. Le registre coordonne un identifiant ; il ne prend pas en charge la responsabilité opérationnelle.

Un préfixe court reste une information

Le préfixe transmis peut atteindre plusieurs serveurs faisant autorité et des observateurs du trafic non chiffré. Sa brièveté réduit la précision, mais ne le rend pas anonyme. Le client devrait choisir le plafond le plus court qui conserve l’utilité recherchée.

Le projet inverse un défaut important pour les résolveurs qui l’adoptent : sans signal, rien n’est transmis. Ce gain ne supprime pas la confiance accordée au résolveur. Le client lui confie déjà ses requêtes et lui demande maintenant de respecter une limite supplémentaire. Le chiffrement protège la route vers cet acteur ; il ne remplace pas son obligation.

La conséquence pour les dirigeants est simple. La confidentialité ne peut pas être résumée par la présence d’une option ou par l’arrivée d’une réponse. Elle dépend d’une suite de gardes : choix du client, réception directe, limite effective, transfert non transitif, provenance du cache et observation de la divulgation. Le cache n’est pas un détail après le consentement. Il est l’un des lieux où le consentement doit continuer d’exister.

Sources