Résumé

  • Le sous-série BCP 152 ne contient qu'un seul document, et ce document est signé d'une seule personne. À côté, le registre des paramètres DNS de l'IANA tient une table DSO Type Codes avec KeepAlive, RetryDelay et EncryptionPadding. C'est cette table, et non la prose, qui portera encore la trace du mécanisme dans dix ans.
  • RFC 5625 interdit surtout d'abîmer ce que le mandataire ne comprend pas ; RFC 8490 fabrique un état partagé entre deux machines. Ni l'un ni l'autre ne contraint qui refuse d'implémenter, et rien dans le dossier examiné ici ne démontre un effet sur un réseau en production.

Une sous-série d'un seul document

La page de la RFC Editor consacrée à la sous-série BCP 152 affiche une ligne qui mérite d'être lue lentement : « BCP 152 subseries contains 1 RFC ». Un document, seul, dans une catégorie entière.

Ce document est RFC 5625, DNS Proxy Implementation Guidelines, publié en août 2009 (page d'information RFC 5625). Le bloc d'auteur du texte ne mentionne qu'une personne : R. Bellis, de Nominet UK (texte de RFC 5625).

La mention de statut est d'une honnêteté remarquable : le document « specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements ». Autrement dit : voici ce que nous croyons juste, discutez-en. Aucun programme de conformité n'est attaché à cette catégorie. Aucun laboratoire ne délivre de certificat. Un Best Current Practice est un avis motivé, adressé à des gens libres de ne pas le suivre.

Des verbes impératifs qui protègent surtout l'inconnu

Ce que RFC 5625 ordonne le plus fermement concerne moins les fonctions à ajouter que le sens à ne pas détruire :

  • Section 4.1 : les mandataires MUST ignorer tout indicateur DNS inconnu et transmettre ces paquets tels quels.
  • Section 4.4 : si un mandataire doit tronquer une réponse de sa propre initiative, il MUST positionner le bit TC.
  • Section 4.5 : les mandataires DNS MUST être capables de relayer des paquets contenant des enregistrements TKEY.

Trois obligations, trois interdictions de nuire. Le texte n'exige jamais d'un boîtier qu'il implémente une nouveauté ; il lui interdit de détruire une signification qui ne lui appartient pas.

L'ambition positive est écrite plus doucement. La section 3 se contente de recommander que les mandataires soient aussi transparents que possible. La section 4.4.1 veut qu'une requête reçue en TCP soit transmise en TCP, sans tentative préalable en UDP. La section 5.2 préfère une valeur par défaut vide pour l'option qu'elle décrit. Transparence : recommandation. Ne pas casser : obligation.

Ce n'est pas de la prudence excessive. Un mandataire résidentiel vit plus longtemps que la norme qu'il sert. Son micrologiciel cesse d'évoluer bien avant le DNS. L'auteur ne peut pas savoir ce qu'une extension future exigera de cet appareil, et la seule règle tenable devient celle qu'il a écrite : achemine ce que tu ne comprends pas, et signale honnêtement quand tu tronques.

Des obligations qui constituent un objet partagé

RFC 8490, DNS Stateful Operations, est un Proposed Standard de mars 2019 qui met à jour RFC 1035 et RFC 7766 (page d'information RFC 8490). Il porte six signatures : R. Bellis (ISC), S. Cheshire (Apple), J. Dickinson et S. Dickinson (Sinodun), T. Lemon (Nibbhaya Consulting) et T. Pusateri, non affilié (texte de RFC 8490).

Sa mention de statut est la formule de la voie normes : le document représente le consensus de la communauté IETF, a reçu une relecture publique et a été approuvé pour publication par l'Internet Engineering Steering Group. L'autorité dont il dispose est empruntée à un processus qui compte des relecteurs ; elle n'est pas revendiquée par ses auteurs.

Et ses impératifs construisent quelque chose, là où ceux de RFC 5625 se contentaient d'empêcher :

  • Section 5.1 : un serveur MUST NOT émettre de message de requête DSO ni de message unidirectionnel DSO avant qu'une session DSO ait été établie mutuellement.
  • Section 5.1.1 : un serveur mettant en œuvre DSO MUST NOT renvoyer DSOTYPENI en réponse à une requête Keepalive, le TLV Keepalive étant obligatoire à implémenter.
  • Section 5.4.1 : si une réponse DSO arrive avec un MESSAGE ID nul, l'erreur est fatale et le destinataire MUST interrompre brutalement la connexion.

Lues à la suite, ces phrases décrivent une institution à deux membres. Une session n'existe que par établissement mutuel. Un code de refus nommé devient indisponible pour une requête précise, parce qu'une autre pièce est obligatoire. Un identifiant malformé n'est pas un avertissement mais une rupture. Deux machines détiennent désormais un état conjoint qu'aucune ne peut déclarer seule, et le document est l'endroit où cette conjonction est écrite.

Autour de ces interdictions, les rédacteurs ont laissé de la discrétion, et l'ont marquée comme telle. Un client sans réponse SHOULD attendre trente secondes. Un client dont le serveur coupe la connexion SHOULD considérer que cette instance de service ne prend pas en charge DSO. Ce sont des consignes de lecture du silence, d'une autre nature que les règles de constitution d'une session.

Ce que le dossier ne tranche pas

Trois questions naturelles restent ouvertes, et il vaut la peine de dire pourquoi avec précision.

Le registre d'abord, mais dans l'autre sens. La table des OpCodes des paramètres DNS de l'IANA attribue la valeur 6 à « DNS Stateful Operations (DSO) » avec renvoi à RFC 8490, et la table voisine DSO Type Codes fixe 0x0001 KeepAlive, 0x0002 RetryDelay, 0x0003 EncryptionPadding. Une attribution de registre est un acte public d'une espèce particulière : elle ne dépend pas de la participation continue de l'auteur, elle n'expire pas avec son contrat de travail, et elle ne demande le consentement de personne pour rester au catalogue. Elle ne dit pas, en revanche, quel logiciel l'utilise.

Les corrections ensuite. À la date du 18 octobre 2026, les pages d'errata affichaient zéro entrée pour RFC 5625 comme pour RFC 8490, et aucune page d'information n'indiquait de document successeur ou d'obsolescence. Un affichage vide est un signal faible : il peut signifier que le texte a tenu, ou que personne n'a déposé de correction. Ce sont deux faits différents qui se ressemblent de l'extérieur.

La fabrication du document enfin. Les fiches Datatracker de RFC 5625 et de RFC 8490 n'étaient disponibles ici que sous forme de résumés de page, non d'historiques de révision complets : la filiation des groupes de travail est visible — DNSEXT pour le guidage des mandataires, DNSOP pour les opérations avec état — mais l'histoire phrase par phrase ne l'est pas.

Et surtout : aucune preuve de mise en œuvre n'a été obtenue pour l'un ou l'autre document. Cet article ne soutient donc ni que RFC 5625 a modifié la façon dont les passerelles relaient les requêtes, ni que DSO apparaît dans un résolveur commercialisé. Ce sont des questions empiriques sur du code, et le code n'a laissé aucune trace dans le dossier examiné.

Où s'arrête réellement l'auteur

La tentation, avec un ingénieur comme Bellis, est de lire le numéro de RFC comme une preuve du réseau. Il ne l'est pas. Le numéro atteste qu'un document a été publié, relu et catalogué ; il ne dit rien des machines qui exécutent ce qu'il décrit. La conformité se manifeste dans le déploiement, et le déploiement est la décision de quelqu'un d'autre.

Ce que l'auteur contrôlait est plus étroit et plus intéressant. Il contrôlait la formulation : quelle exigence devenait un MUST, laquelle restait un RECOMMENDED, et — dans RFC 5625 surtout — si les verbes les plus forts serviraient à interdire les dégâts ou à réclamer des fonctions. Il contrôlait, avec cinq coauteurs, le choix de faire de l'établissement de session une condition préalable plutôt qu'une politesse. Ce sont des actes réels, attribuables à des personnes nommées, et visibles dans le texte.

Ce qu'il ne contrôlait pas, c'est la partie qui décide si tout cela compte. Un implémenteur peut lire RFC 8490, peser le coût d'un état de session contre un calendrier de micrologiciel, et refuser. Rien dans le document ne l'atteint. Le registre conserve pourtant le numéro — et c'est précisément pourquoi le registre témoigne mieux de la durabilité que la prose ne témoigne de l'adoption.