Résumé

  • WKS décrivait les services d’une adresse IPv4 au moyen d’un numéro de protocole et d’un bitmap de ports. La précision du codage masquait la fragilité de la déclaration : un bit publié n’était pas une mesure de disponibilité.
  • La RFC 974 encourageait les logiciels de courrier à éliminer les cibles MX qui n’annonçaient pas SMTP dans WKS. La RFC 1123 a retiré cette recommandation, car un type peu utilisé ne permettait pas de confondre absence de déclaration et absence de service.
  • Le registre de ports, l’administrateur DNS, le processus serveur, la politique réseau et l’authentification applicative détenaient chacun une partie de la réponse. Aucun ne pouvait être remplacé par le seul bit 25.

Un verdict avant la connexion

Le logiciel de courrier dispose d’une liste de serveurs MX. Avant de contacter le premier, il interroge encore le DNS. Cette fois, il ne cherche pas une adresse : il veut savoir si l’adresse propose SMTP. Un enregistrement WKS lui fournit un protocole et une suite de bits. Pour TCP, le bit numéro 25 correspond au port 25. S’il vaut un, un serveur SMTP devrait être à l’écoute.

Dans le monde décrit par les premières spécifications, ce petit contrôle semblait raisonnable. Une tentative infructueuse prend du temps. Plusieurs cibles peuvent devoir être essayées. Un catalogue de services permettrait de retirer celles qui ne conviennent pas et de réserver les connexions aux candidats utiles.

Mais le contrôle transformait aussi une déclaration administrative en décision opérationnelle. Le serveur DNS n’avait pas interrogé le processus SMTP à l’instant de répondre. Il ne connaissait pas nécessairement les filtres sur le trajet du client. Il renvoyait ce que la zone avait publié, éventuellement depuis un cache. La différence entre « devrait écouter » et « répond maintenant » allait devenir décisive.

Le service réduit à une position

La RFC 883 définissait WKS dès novembre 1983. La RFC 1035, en novembre 1987, en conservait le principe : une adresse Internet de 32 bits, un numéro de protocole IP de huit bits, puis un bitmap de longueur variable, toujours multiple de huit bits.

Chaque position représente un port du protocole choisi. La première est le port zéro, la suivante le port un. Toute position au-delà de la fin transmise est considérée comme nulle. Le texte donne SMTP comme exemple : avec TCP, le vingt-sixième bit représente le port 25 ; s’il est actif, un serveur devrait écouter, sinon le service n’est pas pris en charge à cette adresse.

Le choix de l’adresse littérale importe. WKS ne désigne pas un nom de cible à résoudre plus tard, ni une instance de service qui pourrait déménager. Il décrit un couple adresse-protocole. Une machine dotée de plusieurs adresses nécessite plusieurs enregistrements. TCP et UDP demandent également des enregistrements distincts.

Le bitmap est dense. Son coût dépend du port le plus élevé annoncé, pas du nombre de services. Deux ports éloignés obligent à conserver les positions intermédiaires ; seule la fin composée de zéros peut être omise. C’est une propriété arithmétique du format, non une mesure de gaspillage observée. Elle révèle néanmoins le modèle implicite : les services sont les cases d’un espace de numéros bien connus.

Il n’existe ni priorité, ni poids, ni cible de secours, ni port propre à une instance, ni état de maintenance. Plusieurs WKS peuvent énumérer plusieurs couples, mais ils ne disent pas au client comment arbitrer entre eux. Le format publie un inventaire, pas une procédure de sélection.

Quand l’inventaire devient un filtre

La RFC 974, publiée en janvier 1986, a donné à cet inventaire un rôle dans le routage du courrier. Pour chaque MX, elle encourageait fortement une requête WKS afin de vérifier la prise en charge du service demandé. Les cibles qui ne le proposaient pas devaient être retirées.

L’idée suppose un monde où les inventaires sont complets. Dans ce monde, un zéro est une information utile : inutile d’essayer SMTP sur une machine qui n’en dispose pas. Dans un déploiement facultatif, le même zéro ou la même absence peut signifier autre chose : personne n’a créé le WKS, le service a été ajouté sans mise à jour DNS, ou la zone conservée par le résolveur est ancienne.

La différence n’est pas cosmétique. Une cible MX parfaitement capable d’accepter du courrier peut disparaître du plan de livraison avant le premier SYN. Une optimisation destinée à éviter l’échec devient elle-même une source d’échec. Le catalogue n’est plus seulement incomplet ; il dispose d’un pouvoir de veto qu’il ne peut justifier.

Même un bit positif n’épuise pas l’incertitude. Le démon peut s’arrêter pendant le TTL. Une adresse peut être réaffectée. Un pare-feu peut bloquer un client sans bloquer les autres. Un autre programme peut occuper le port. Et une connexion TCP réussie ne prouve encore ni l’identité du service ni l’acceptation du message.

Ce n’est pas un défaut accidentel du cache. Le DNS gagne en efficacité précisément parce qu’il n’exige pas de consulter le producteur de données à chaque utilisation. Cette économie rend impossible l’assimilation automatique d’un enregistrement à une sonde en temps réel.

La règle de 1989 : essayer le service

En octobre 1989, la RFC 1123 consignait le résultat de l’expérience. Une application ne devait pas compter sur la présence d’un WKS contenant une liste exacte de tous les services d’une adresse, car les sites Internet utilisaient peu ce type. Pour confirmer la présence d’un service, il fallait tenter de l’utiliser.

Le texte revenait séparément sur le courrier. Le contrôle WKS conseillé par la RFC 974 ne devait plus être employé dans le traitement MX, le support s’étant révélé trop limité. La correction ne proposait pas un bitmap plus sophistiqué. Elle retirait au catalogue le droit d’empêcher une tentative.

Il faut lire cette décision sans l’exagérer. Un WKS bien maintenu pouvait être exact. La RFC 1123 n’a pas supprimé le type 11. Le registre DNS de l’IANA continue de l’attribuer à WKS. Une allocation durable évite la collision des codes et permet d’interpréter les données anciennes ; elle ne mesure pas l’usage contemporain.

Ce qui a été abandonné est une inférence : l’absence dans un répertoire facultatif ne prouve pas l’absence dans le réseau. Pour le courrier, le risque de rejeter à tort une cible valable dépassait le coût d’un essai. La confirmation devait revenir au protocole et au client.

Le registre ne commande pas au processus

Une phrase comme « cette adresse offre SMTP » rassemble plusieurs autorités. Le registre associe un numéro à un usage pour coordonner les implémentations. L’administrateur DNS publie une intention dans une zone. L’administrateur système fait écouter un processus. Les opérateurs réseau ouvrent ou ferment les chemins. Enfin, l’application vérifie ce qui répond et sous quelle identité.

Un enregistrement peut être authentique du point de vue DNS et néanmoins dépassé du point de vue du serveur. Il peut être exact pour un client local et inutilisable depuis un autre réseau. Un port ouvert peut recevoir un protocole différent. La confiance dans une couche ne se transfère pas automatiquement à la suivante.

La RFC 6335 a ensuite explicité la limite du registre. L’attribution d’un nom ou d’un port ne constitue pas une approbation d’un produit. Le trafic sur un port attribué n’est pas nécessairement légitime, ni même celui du service enregistré. Les administrateurs doivent fonder leur politique sur leur connaissance du trafic, pas sur le seul numéro.

Cette formulation est postérieure à WKS ; elle n’est pas projetée artificiellement dans les années 1980. Elle éclaire cependant la même erreur de catégorie : un identifiant commun n’est pas la preuve d’une activité présente, encore moins une permission d’accès.

Nommer une cible plutôt que cocher un port

Avec la RFC 2782, SRV a exprimé la localisation autrement. La requête nomme un service et un transport dans un domaine ; la réponse fournit priorité, poids, port et cible. Cette cible est un nom de machine possédant des adresses, et non une adresse IPv4 incorporée au catalogue.

Le service peut alors être déplacé entre hôtes, disposer de plusieurs candidats et utiliser le port annoncé pour chacun. C’est une rupture d’expression : le client reçoit un ensemble limité de choix, pas la totalité supposée des services d’une adresse. La RFC 6335 a ensuite permis l’enregistrement d’un nom de service sans port fixe lorsque la découverte fournit celui-ci à l’exécution.

SRV n’a pourtant pas réglé la question de la vie du processus. Les poids ne sont pas une télémétrie instantanée. Une cible peut tomber après mise en cache. La connexion et l’identification applicative restent nécessaires. L’évolution n’a pas rendu le DNS omniscient ; elle a mieux séparé ce qu’il publie de ce que le client doit éprouver.

Ce que permet cette histoire

Les sept sources officielles retenues établissent le format initial, son emploi proposé dans MX, le retrait de cette pratique, la distinction ultérieure entre nom et port, et le maintien de l’allocation type 11. Elles ne comptent pas les zones WKS actuelles, ne mesurent pas les requêtes et ne prouvent pas la conformité d’un logiciel donné.

Elles ne montrent pas non plus qu’un enregistrement particulier était périmé, que tous les logiciels de courrier appliquaient la RFC 974, ou que SRV a remplacé chaque usage de WKS. La leçon repose sur une évolution normative documentée, non sur un récit inventé de panne universelle.

Le bit était parfaitement lisible. Ce qui lui manquait était le mandat de parler pour un système vivant. WKS pouvait annoncer une configuration ; il ne pouvait ni maintenir un processus, ni ouvrir un chemin, ni authentifier la réponse. L’Internet a gagné en robustesse lorsque l’absence de ce bit a cessé d’interdire l’expérience qui pouvait réellement répondre.