Résumé

  • RFC 9083 définit port43 comme un nom d’hôte ou une adresse IP du serveur WHOIS où l’objet concerné peut se trouver.
  • Cette valeur ne constitue ni une URI, ni une preuve que le service existe toujours, ni une promesse que ses données correspondent à celles de RDAP.

Une réponse courte, destinée à une personne

En 1982, NICNAME/WHOIS était décrit comme un service de répertoire du SRI-NIC accessible par une transaction simple. Le client se connectait au port TCP 43, envoyait une ligne de commande terminée par CRLF, recevait une réponse puis voyait le serveur fermer la connexion. Le protocole NCP disposait également d’un accès au socket 43. Les résultats — noms, boîtes aux lettres et autres données du répertoire — étaient présentés en texte pour être lus par une personne. Une ligne « ? » demandait au serveur la syntaxe de recherche alors en vigueur, appelée à évoluer.

La mise à jour de 1985 précisait ce que cette interface pouvait faire. Une requête pouvait viser un nom, un identifiant ou une boîte aux lettres ; un astérisque en tête pouvait demander la liste complète des membres d’un groupe, ou des utilisateurs autorisés d’un hôte. Le RFC avertissait qu’une longue liste pouvait prendre beaucoup de temps. Le périmètre de la recherche pouvait donc changer fortement avec un seul caractère, tandis que la réponse demeurait un texte à présenter directement à l’utilisateur, pas un modèle d’objet stable pour un logiciel.

port43 ne contient pas cette ancienne réponse. Il nomme le service susceptible de détenir des informations sur l’objet. Il faut distinguer la représentation des données et la destination d’un autre système capable de fournir des données à son sujet.

RDAP a modifié la forme de l’échange

En 2004, RFC 3912 a recentré la spécification WHOIS sur le protocole sur le fil. Le serveur écoutait toujours sur TCP 43 ; le client envoyait une requête textuelle et recevait du texte. La fermeture de la connexion signalait la fin de la réponse. Le protocole ne fournissait pas de schéma de résultat normalisé, d’indication de jeu de caractères, de contrôle d’accès, de mécanisme d’intégrité ou de confidentialité. Ces limites sont celles que documente le RFC ; elles ne démontrent pas que tous les anciens services se comportaient de manière identique ou que chaque inscription était inexacte.

Le travail RDAP de 2015 visait une interface commune différente. RFC 7480 spécifiait le comportement HTTP des services de données d’enregistrement et demandait des requêtes et réponses normalisées, des redirections et la prise en charge des noms internationalisés et des données localisées. RFC 7481 décrivait des services de sécurité, dont l’authentification et le contrôle d’accès, pouvant s’appuyer sur d’autres couches protocolaires. En 2021, RFC 9082 définissait les formes de requête et RFC 9083 les structures JSON des réponses.

Le nouveau format n’avait pas à faire comme si l’ancien service avait disparu. La section 4.7 de RFC 9083 définit port43 comme une chaîne contenant le nom d’hôte complet ou l’adresse IP du serveur WHOIS où l’objet concerné peut se trouver. Le texte fixe une limite précise : ce n’est pas une URI, puisqu’il n’existe pas de schéma URI pour WHOIS. Les exemples donnent un nom comme whois.example.net.

Une référence ne fait pas une passerelle

Ce membre rend visible la transition dans l’objet lui-même : un client reçoit une structure RDAP et peut aussi apprendre qu’un serveur WHOIS lui est associé. C’est un indice de compatibilité, pas une conversion de transport. port43 ne transmet ni commande WHOIS, ni grammaire de recherche, ni format de réponse, ni identifiant d’accès, ni règle qui permettrait de décider si les deux résultats décrivent exactement la même inscription actuelle.

La formule « peut se trouver » borne également la portée du champ. Elle n’impose pas que le serveur soit joignable, ne prouve pas son autorité et ne certifie pas que ses réponses reprennent les mêmes valeurs que RDAP. Elle n’établit pas non plus qu’un client RDAP suivra la référence. Ces choix relèvent des opérateurs de registre, des données publiées et de la politique du client.

Le piège est de confondre deux interfaces parce qu’elles exposent des données d’enregistrement. Un nom d’hôte dans un document JSON n’est pas une requête en direct ; une réponse en direct ne prouve pas davantage la légitimité ou l’exactitude d’une donnée. RDAP a structuré l’interface. port43 a conservé le nom d’un service voisin sans prétendre unifier les systèmes qui se cachent derrière.

Ce que les opérateurs devraient surveiller

Un système qui consomme les deux interfaces peut vérifier séparément la présence de port43, la validité du nom d’hôte ou de l’adresse, la joignabilité du port TCP 43 selon la politique attendue, puis la comparabilité de l’objet retourné. Une référence modifiée ou absente justifie l’examen d’une dépendance ; elle ne prouve pas à elle seule un transfert de ressources, un changement de routage ou un déplacement d’autorité d’enregistrement.

Une intégration doit décider explicitement si elle tentera WHOIS, quelle syntaxe elle enverra, comment elle traitera les délais d’attente et ce qui constituera un écart. Laisser ces règles implicites transformerait une adresse de serveur possible en dépendance d’exécution cachée.

Sources