Résumé

  • La révision 03 du projet DNSOP consacré à GREASE veut exercer des points d’extension avec des valeurs non attribuées, afin d’éviter que logiciels et intermédiaires ne figent les usages actuels. C’est un Internet-Draft actif et inachevé, non une RFC ni un mandat de déploiement.
  • Le repli séquentiel et la requête témoin en parallèle ne distribuent pas le même coût : le premier peut augmenter la latence, la seconde le volume reçu par l’autorité. Un essai lancé par le serveur est encore plus délicat, car celui-ci ne voit pas nécessairement l’échec en aval.
  • Avant toute activation par défaut, une charte datée devrait fixer le champ testé, l’algorithme de valeurs, les plafonds de trafic et d’échec, la collecte, la protection contre l’empreinte, l’échéance et le responsable de l’arrêt. Cette charte est une proposition de Daniel Kade, pas une règle de l’IETF.

Une extension peut rester parfaitement normalisée et pratiquement inutilisable. Il suffit que, pendant des années, les équipements ne rencontrent que les mêmes numéros. Un développeur finit par transformer une liste observée en liste autorisée. Une passerelle rejette ce qu’elle ne reconnaît pas. Rien ne casse tant qu’aucune nouveauté n’arrive ; le défaut n’apparaît que lorsque l’écosystème a déjà besoin du changement.

GREASE sert à ne pas attendre ce moment. Le procédé injecte régulièrement des valeurs sans fonction utile, qui doivent être ignorées à la réception. La RFC 8701 l’a consacré pour TLS sous forme de valeurs réservées et espacées. Un pair conforme poursuit l’échange ; un pair intolérant révèle assez tôt une articulation rouillée.

Le projet Greasing Protocol Extension Points in the DNS transpose cette logique au DNS. Sa révision 03, publiée le 6 juillet 2026, est un document de travail du groupe DNSOP. Elle expire le 7 janvier 2027 et peut encore être remplacée. Surtout, elle montre elle-même que les choix structurants ne sont pas clos : pas de consensus sur les plages réservées, section des valeurs encore vide, comportement détaillé et actions IANA à compléter.

Ces lacunes ne condamnent pas l’idée. Elles interdisent de confondre une technique prometteuse avec une politique d’exploitation prête à devenir silencieusement la valeur par défaut.

Le DNS ne propose pas une seule prise d’extension

Le projet recense le dernier drapeau de l’en-tête DNS, l’Opcode, la version EDNS, les drapeaux EDNS, la Class, le type de ressource et le code d’option EDNS. Leurs tailles vont d’un bit à 65 536 valeurs. Le nombre de valeurs aujourd’hui libres varie avec les attributions IANA. Certaines zones du registre sont expérimentales ou privées ; d’autres sont simplement non attribuées.

Les RCODE et RCODE étendus sont absents de la liste. Ce choix est essentiel : ils décrivent l’état d’une réponse. Les modifier changerait ce que le demandeur croit avoir reçu. GREASE vise au contraire des valeurs inconnues que le récepteur conforme doit tolérer sans altérer le service.

Il serait donc trompeur de parler de paquet malformé. Une valeur GREASE est construite pour n’avoir aucune signification fonctionnelle et pour être ignorée. L’échec signale une intolérance à l’inconnu, non la découverte automatique d’un acteur coupable.

La diversité des champs empêche aussi un bouton global d’être suffisamment précis. Une option EDNS comporte un code et des données qu’il faut générer. Un nouveau type de ressource peut obliger à construire une autre question. Une plage adaptée à un espace de seize bits serait absurde pour un drapeau unique. L’autorisation doit nommer le champ, la direction et le comportement exacts.

Le choix du repli choisit aussi le payeur

Lorsque la requête graissée échoue, un résolveur peut recommencer sans l’extension. C’est le chemin séquentiel. Il protège la compatibilité, mais ajoute le temps de l’échec initial. Si les tableaux de bord ne conservent que la réponse finale, l’expérience disparaît précisément parce que le repli a réussi.

Le résolveur peut également envoyer deux requêtes en parallèle. La requête normale sert l’utilisateur ; la requête graissée ne sert qu’à mesurer. La latence visible est mieux protégée, au prix d’un volume supplémentaire pour le serveur faisant autorité et pour les réseaux intermédiaires.

Ces deux architectures n’ont pas le même budget. L’une consomme du délai et parfois des tentatives ; l’autre, des paquets, du calcul et des journaux. Toutes deux réclament de la capacité d’analyse et de correction. Le bénéficiaire immédiat de l’information est l’initiateur, alors qu’une part du coût tombe chez son interlocuteur.

La révision 03 recommande de n’utiliser qu’un échantillon et écrit, avec un point d’interrogation, « peut-être une requête sur mille ». Ce nombre n’est ni un seuil normatif ni une preuve de sûreté. Un millième d’un petit résolveur d’entreprise et un millième d’un service mondial n’ont ni le même débit, ni les mêmes destinations, ni le même impact.

Une charte crédible combine donc un pourcentage et un plafond absolu. Elle limite également le débit par destination, exclut les périodes d’incident et les services fragiles, et mesure séparément les requêtes parallèles, les délais de repli et les échecs visibles. Le réglage doit pouvoir être interrompu sans attendre le prochain déploiement logiciel.

Le serveur ne voit pas toujours les dégâts qu’il déclenche

Le scénario principal du projet part du résolveur. Celui-ci émet la valeur inconnue, reçoit ou ne reçoit pas la réponse, puis peut comparer avec une requête normale. Il observe au moins la conséquence proche de son action.

Le sens inverse est moins confortable. Un serveur faisant autorité peut insérer un drapeau ou une option inattendue dans sa réponse. Cette méthode est utile pour une expérience ciblée. Mais le serveur ignore parfois si le résolveur a accepté le message, interrogé un autre serveur ou provoqué une panne dans l’application finale.

C’est pourquoi le projet précise que le graissage lancé par le répondeur devrait être désactivé par défaut. Une interface produit ne doit pas gommer cette différence. Autoriser un résolveur à tester ses requêtes n’autorise pas le même opérateur à modifier ses réponses faisant autorité.

Une expérience côté serveur a besoin d’un périmètre nommé, d’observateurs clients externes, de seuils plus bas et d’un arrêt immédiat. Sans visibilité sur la panne aval, aucune statistique du serveur ne suffit à promouvoir automatiquement le test.

Réserver ou piocher dans le libre

Une plage réservée à GREASE présente deux avantages : elle est reconnaissable dans une trace et ne recevra pas demain une fonction ordinaire. Elle porte aussi son propre risque d’ossification. Les logiciels peuvent apprendre à ignorer uniquement la plage connue tout en continuant de refuser toutes les autres nouveautés. L’indicateur devient vert alors que l’aptitude générale n’a pas progressé.

Le tirage dans les valeurs actuellement non attribuées exerce un espace plus large. Mais IANA peut ensuite attribuer l’un de ces numéros à une fonction réelle. Un ancien logiciel, habitué à le jeter, pourrait continuer à ignorer sa nouvelle signification.

Le projet suggère une date de fin préconfigurée ou configurable pour réduire ce risque. Cette date est une propriété de sûreté, pas une simple échéance administrative. Elle force l’expérience à s’arrêter avant que le souvenir de son lancement ne disparaisse et oblige tout renouvellement à comparer un nouvel état des registres.

Le registre IANA des paramètres DNS, mis à jour le 28 août 2026 lors de cette recherche, maintient des tables distinctes pour classes, types, opcodes, options et versions EDNS. Il ne résout pas encore les plages DNS GREASE laissées en discussion dans le projet. Une photographie du registre prouve seulement l’état connu au lancement ; elle ne vaut pas droit perpétuel sur une valeur libre.

Mesurer assez, conserver peu

Une perturbation qui ne produit pas de diagnostic exploitable n’entretient rien. Le projet général sur le graissage rappelle le dilemme : trop rare, l’échec se perd dans le bruit ; trop régulier, le motif devient facile à reconnaître et à traiter spécialement.

Le DNS ajoute l’effet du repli. L’utilisateur peut voir une réussite finale alors que la première transaction a échoué. Il faut donc séparer la santé du service et le résultat expérimental. L’événement minimal associe le point d’extension, la famille de valeur, la version de l’algorithme, la direction, le chemin de contrôle, le résultat proche, la durée et la réponse effectivement remise au client.

Un délai dépassé ne désigne pas un middlebox. Un FORMERR ne prouve pas où le refus s’est produit. La comparaison entre trafic graissé et témoin peut établir une différence reproductible ; l’attribution demande des observations supplémentaires.

La collecte peut elle-même créer une empreinte. La révision 03 avertit qu’un choix non aléatoire peut identifier une implémentation de résolveur. Le projet général étend l’avertissement aux variations de paramètres. Le compromis doit être explicite : un motif stable pendant une version facilite la reproduction, mais rend le produit reconnaissable ; une variation à chaque échange disperse l’empreinte, mais les nouvelles tentatives peuvent masquer les défauts intermittents.

Une politique raisonnable varie à l’intérieur d’une période bornée, minimise les noms collectés, agrège avant partage et détruit les événements bruts après diagnostic. La promesse vague de « télémétrie anonyme » ne remplace pas les champs, durées et destinataires exacts.

La charte avant le bouton

La charte nomme d’abord quatre rôles : qui autorise, qui implémente, qui analyse et qui peut arrêter. Le fait qu’un éditeur livre le code ne prouve pas que chaque exploitant a accepté le même compromis.

Elle décrit ensuite l’objet de fil : champ, ensemble de valeurs, algorithme, charge utile éventuelle, direction et version logicielle. Une copie ou un hachage de l’état IANA lui est joint. Les valeurs réservées, expérimentales, privées et non attribuées restent séparées.

Vient le périmètre : classes de trafic admises et exclues, pourcentage, plafond de débit global et par destination, étapes de déploiement, fenêtre d’observation, repli séquentiel ou témoin parallèle. Les budgets de latence, de volume, de calcul, de journalisation et d’alerte sont distincts.

La charte définit enfin la preuve et le temps. Elle indique ce qu’est un succès, ce qu’un échec permet réellement de conclure, comment les données sont retenues et partagées, quand l’empreinte devient excessive et comment un tiers peut contester une attribution. Chaque test possède un interrupteur indépendant, une date de fin, des seuils d’abandon, un responsable de renouvellement et une retraite automatique si une attribution IANA entre en collision.

GREASE protège une faculté qui ne rapporte rien aujourd’hui : la possibilité de changer demain. Cette patience technique mérite mieux qu’une activation furtive. Elle mérite un accord lisible sur la petite quantité de désordre que l’on accepte de créer maintenant pour éviter une panne beaucoup plus coûteuse plus tard.

Sources

  1. Greasing Protocol Extension Points in the DNS — révision 03
  2. Fiche Datatracker du projet DNS GREASE
  3. Historique du document DNS GREASE
  4. Documents actifs de DNSOP
  5. Charte de DNSOP
  6. RFC 8701 — GREASE pour TLS
  7. RFC 6891 — mécanismes d’extension du DNS
  8. Maintaining Protocols Using Grease and Variability — révision 06
  9. Paramètres DNS administrés par IANA