Résumé

  • Le 9 septembre à 08 h 59 UTC, un auteur a demandé l’adoption d’un nouveau projet de mesure de la latence DNS dans un message intitulé « Call for Adoption ». À 10 h 37, Benno Overeinder, président de DNSOP, a rappelé que les présidents lancent ces appels après une phase de présentation et de discussion.
  • Cette intervention ne rejetait pas le texte. À la clôture de cette enquête, la révision 00 restait un Internet-Draft individuel, au stade I-D Exists, sans adoption par le groupe ni approbation de l’IETF.
  • Le fond du projet renvoie au même principe : deux chiffres appelés « latence DNS » ne sont pas nécessairement comparables. Le rôle de l’émetteur donne son statut à l’appel ; le périmètre et le contexte donnent son sens à la mesure.

Deux horodatages, deux actes différents

Le premier message ne cachait pas son intention. Jishuang Wang écrivait vouloir demander au groupe de travail d’adopter A Framework for DNS Resolution Latency Measurement. Il invitait les membres à se prononcer sur la pertinence du problème pour DNSOP, l’utilité du vocabulaire proposé et l’intérêt d’une adoption comme point de départ.

Ces questions sont des contributions ordinaires et utiles. L’ambiguïté venait de l’objet « Call for Adoption », qui pouvait faire croire que la période formelle de consultation était déjà ouverte.

La réponse de Benno Overeinder a séparé la demande de l’acte institutionnel. Dans DNSOP, a-t-il indiqué, les présidents lancent les appels à l’adoption. Le projet doit auparavant être discuté sur la liste et, de préférence, présenté pendant une séance du groupe. L’annonce par l’auteur constitue la première étape, sans cette formule dans l’objet. Après la discussion et selon l’intérêt manifesté, les présidents peuvent ouvrir l’appel en troisième étape.

Il ne s’agissait ni d’un refus, ni d’une appréciation sur la qualité du projet. La réponse corrigeait le type d’événement. À 08 h 59, il existait une demande d’auteur ; à 10 h 37, il n’existait toujours pas de preuve qu’un appel officiel avait commencé.

Le registre ne laisse pas de place à l’ellipse

Le Datatracker décrit la révision 00 comme un Internet-Draft individuel actif, dans l’état I-D Exists. Son avertissement est explicite : chacun peut soumettre un I-D ; ce document n’est pas approuvé par l’IETF et ne possède aucun statut formel dans le processus de normalisation.

L’historique contient le dépôt initial du 9 septembre, sans événement d’adoption. L’en-tête du texte vise un statut Informational et annonce une expiration au 13 mars 2027 ; le champ formel « Intended RFC status » du Datatracker reste vide. Il serait incorrect de fusionner ces deux informations.

La chaîne de preuve doit conserver chaque marche :

annonce de l’auteur ≠ appel lancé par les présidents ≠ évaluation de l’intérêt du groupe ≠ adoption ≠ progression IETF ≠ publication RFC.

Un événement ultérieur pourra changer l’état. Le vocabulaire anticipé d’un message ne peut pas le changer rétroactivement.

L’ouverture repose sur des rôles lisibles

Une procédure ouverte n’accorde pas le même pouvoir à tous les actes. Elle permet à chacun de proposer un texte, d’en contester les hypothèses et de demander qu’il soit repris par un groupe. Elle réserve cependant à des rôles identifiés la conduite des consultations et la déclaration d’un résultat.

La RFC 2418 place l’essentiel du travail sur les listes de diffusion. Elle confie aux présidents la gestion du processus et l’appréciation du consensus approximatif. Le volume de messages n’est pas, à lui seul, une mesure du consensus. La RFC 7282 ajoute que les objections techniques doivent être réellement examinées : cent réponses favorables n’effacent pas une question substantielle laissée sans réponse.

Ces RFC ne décrivent pas mot pour mot les trois étapes citées par le président de DNSOP. La source de cette pratique locale est son message. Elles expliquent en revanche pourquoi un appel doit avoir un auteur institutionnel identifiable, une révision visée, une durée et un responsable de l’évaluation.

Sans cette séparation, plusieurs participants pourraient créer plusieurs « appels » concurrents par leurs seuls objets de courriel. Les moteurs de recherche retiendraient le titre le plus affirmatif ; le groupe, lui, ne saurait toujours pas quelle version ni quelle échéance font foi.

Une même unité peut cacher plusieurs parcours DNS

Le projet de révision 00 part d’une autre ambiguïté nominale. Une valeur en millisecondes appelée « latence DNS » peut couvrir la résolution entière ou seulement un segment du parcours.

Son modèle distingue TC1, la communication entre client et résolveur récursif ; TC2, le traitement dans le résolveur, qui peut comprendre la consultation du cache, l’application de règles, la validation DNSSEC et la construction de la réponse ; et TC3, les échanges entre résolveur récursif et serveurs faisant autorité.

Une mesure de bout en bout peut réunir TC1, TC2 et TC3. Une mesure prise dans un résolveur peut isoler TC2. Un test entre client et résolveur ne dit rien de TC3. La RFC 9499 stabilise la terminologie des rôles DNS, mais elle ne permet pas de deviner où un chronomètre a démarré.

Le cache, le protocole de transport, le type de requête, la connectivité, la géographie, la configuration du résolveur et l’architecture de déploiement modifient encore l’interprétation. La RFC 7858 décrit notamment l’établissement et la réutilisation des connexions DNS sur TLS ; la RFC 9250 définit DNS sur QUIC. Elles ne démontrent pas qu’un transport est plus rapide. Elles montrent pourquoi son nom et l’état de la connexion doivent accompagner la durée observée.

Deux médianes exactes peuvent ainsi répondre à deux questions différentes. Deux P95 peuvent refléter des intervalles, des populations de requêtes ou des méthodes d’échantillonnage incompatibles. La précision arithmétique n’est pas la comparabilité.

Le passeport de mesure fixe le sens avant le classement

Le projet propose un gabarit descriptif : identifiant et objectif de la mesure, périmètre, point d’observation, composants temporels, contexte, intervalle, méthode d’échantillonnage, représentation statistique et notes.

Son exemple, déclaré purement illustratif, observe TC3 depuis un résolveur récursif lors d’un défaut de cache, sur DNS over QUIC et IPv6, vers un service faisant autorité anycast. Il couvre le premier trimestre 2026, utilise une observation passive, indique une médiane de 14,2 ms et un P95 de 27,6 ms, puis précise que la validation DNSSEC est activée.

Tous les champs ne sont pas imposés dans chaque cas. Le déploiement peut être progressif. Mais une omission réduit la possibilité d’interpréter et de comparer. L’interopérabilité recherchée ne signifie pas que des logiciels différents doivent produire la même valeur ; elle signifie qu’un lecteur peut comprendre correctement leurs résultats.

Ce « passeport » est plus utile qu’un score synthétique sans contexte. Il laisse à l’opérateur le choix de la sonde et de la méthode, tout en empêchant le tableau de bord de fabriquer une compétition entre objets différents.

Une enveloppe pour l’état, une autre pour le nombre

La correction de procédure et le projet de mesure enseignent la même prudence : l’étiquette extérieure ne doit pas modifier silencieusement la nature de ce qu’elle contient.

Je propose donc une enveloppe de provenance d’état et de mesure. Ce dispositif est une proposition éditoriale, pas une exigence de DNSOP ou de l’IETF.

Le volet procédure conserverait le nom, la révision et l’empreinte du projet ; l’identifiant et l’heure de l’annonce ; le rôle de l’émetteur et l’action demandée. Un éventuel appel ultérieur des présidents disposerait de son propre identifiant, de ses dates et de la révision visée. Les questions techniques seraient reliées comme telles, sans être réduites à un comptage. Seule la déclaration des présidents inscrirait le résultat et le prochain état. Les mentions de shepherd, de flux RFC, d’IESG ou de RFC n’apparaîtraient qu'au moment où elles existent.

Le volet mesure reprendrait les attributs du projet : objectif, périmètre, point, combinaison TC1/TC2/TC3, contexte, intervalle, échantillonnage, statistique et notes. La donnée brute peut rester protégée chez son gardien ; l’affirmation publique doit conserver son sens vérifiable.

Les deux volets restent autonomes. Une adoption future ne validerait aucune performance. Une mesure exemplaire ne donnerait aucun statut institutionnel au document qui la décrit.

Le Policy Mirror de Heng Lu demande de garder visibles l’acteur, la règle et la preuve adaptée à l’état. La Minimum Initial Specification invite à limiter le noyau commun pour préserver le choix local. Why BTW Media Exists fixe enfin la discipline journalistique : ne pas transformer une demande en appel, ni un chiffre en comparaison.

La réponse du président tient en quelques lignes. Elle évite pourtant que l’archive attribue au groupe une décision qu’il n’a pas prise. Le projet de mesure poursuit la même ambition à l’échelle opérationnelle : empêcher qu’un nombre acquière, par répétition, un sens que sa collecte n’a jamais établi.

Sources

  1. Message de l’auteur à DNSOP
  2. Correction du président de DNSOP
  3. Fiche Datatracker
  4. Internet-Draft, révision 00
  5. Historique Datatracker
  6. Charte DNSOP
  7. RFC 2418
  8. RFC 7282
  9. RFC 9499
  10. RFC 7858
  11. RFC 9250
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists