Résumé

  • La RFC 2219 a rassemblé les étiquettes DNS que personnes et logiciels employaient déjà pour repérer des services, afin que leur nom stable survive au déplacement d’un serveur.
  • Elle précise aussi ce que l’étiquette ne démontre pas : ni adresse, ni processus à l’écoute, ni port attendu, ni acceptation du client, ni annuaire complet des services.

Le nom semblait promettre davantage que la réponse DNS

Saisir www.exemple.fr donne l’impression d’indiquer une destination. Cela ne suffit pas. La réponse DNS peut ne fournir aucune adresse ; une adresse peut désigner une machine sans serveur HTTP ; le processus peut écouter ailleurs que sur le port 80 ; et un serveur opérationnel peut refuser une requête particulière. En octobre 1997, la RFC 2219 a rendu cette séparation explicite en proposant de régulariser des noms que les utilisateurs savaient déjà deviner.

La convention avait une utilité immédiate. Une personne pouvait essayer www, ftp ou mail sans connaître le nom de la machine. Un programme pouvait faire la même supposition. Surtout, l’administrateur pouvait conserver ce nom de service même si l’hôte ou ses adresses changeaient. Le visiteur ne devait pas apprendre un nouveau nom à chaque déplacement. La RFC présentait cette indirection comme un moyen de déplacer un service entre machines et comme un indice qu’une organisation pouvait exploiter ce service.

Le texte n’ajoutait ni nouveau type d’enregistrement DNS ni annuaire universel. Publié comme Best Current Practice, il réunissait des usages que ses auteurs qualifiaient de pratique presque universelle, sans fournir de mesure indépendante de cette diffusion. Il proposait des valeurs par défaut — www, ftp, gopher, ldap, mail, news, ntp, pop, whois, entre autres. Pour un protocole absent de la liste, sa spécification devait proposer un nom. La normalisation portait sur le vocabulaire, pas sur une transaction capable de vérifier ce que cachait chaque étiquette.

La réserve est au cœur du document. Une entrée nommée www n’enregistre pas un service Web. Elle n’a pas besoin de résoudre vers une adresse. Aucun hôte n’est tenu d’écouter en HTTP, et rien ne l’oblige à employer le port 80. Même si ces conditions sont réunies, le serveur peut refuser des clients inconnus. La RFC parle donc d’« indices » et demande aux implémenteurs de les traiter comme tels. Le nom est publié dans la zone DNS d’une organisation ; le comportement du service se joue ailleurs.

L’indice intervient également plus tard dans la chaîne de découverte qu’on ne le croit. Il faut déjà connaître le domaine de l’organisation. La RFC 2219 ne permet pas à un programme de déduire ce domaine du nom d’une institution, de son lieu ou de son activité. Elle ne résout pas non plus les cas où un service exige d’autres paramètres qu’un nom d’hôte : son exemple est LDAP, dont un client a besoin pour connaître une base de recherche afin de dialoguer utilement. L’alias facilite l’accès à un domaine déjà connu ; il ne transforme pas DNS en annuaire général.

Déplacer l’étiquette déplaçait aussi la charge de maintenance

La RFC montre deux façons de publier un nom de service. Un CNAME peut faire de ph.exemple.fr un alias du nom canonique d’une machine. Cela évite de répéter les adresses lors d’un déplacement, mais les règles DNS interdisent d’associer d’autres données au propriétaire du CNAME, par exemple un MX. Autre possibilité : publier une ou plusieurs adresses A directement sous le nom de service. Les données d’adresse restent alors visibles à cet endroit, mais il faut les synchroniser avec les hôtes concernés. La RFC refuse de recommander une formule valable pour tous : les besoins locaux décident.

Cette commodité crée une dette opérationnelle. Avec un alias, il faut maintenir sa cible et retirer l’enregistrement lorsque celle-ci disparaît. Une cible périmée reste une cible, pas un contrôle de santé. Avec des adresses directes, il faut aligner le jeu d’adresses du nom de service sur les machines qui servent effectivement les clients. Plusieurs adresses peuvent représenter des miroirs ; la RFC note que les serveurs DNS peuvent les réordonner et que certains clients utilisent leurs propres heuristiques. Cela ne prouve ni leur disponibilité ni leur identité. Le texte juge cette option pertinente seulement si les copies sont exactes.

La sécurité découle de la même limite. Une réponse DNS peut être falsifiée, soit pour empêcher l’accès, soit pour diriger passivement l’utilisateur vers un serveur qui se fait passer pour le bon. La convention ne fournit aucun mécanisme d’authentification. Un nom rassurant ne remplace donc ni la vérification du point d’arrivée ni la protection d’un échange sensible.

Le texte reconnaissait enfin sa portée provisoire. Les noms usuels ne résolvaient pas le problème de fond : trouver un service particulier. Il renvoyait aux travaux sur les Server Location Resource Records, alors désignés par la RFC 2052. La chronologie doit rester précise : cette proposition SRV précédait la RFC 2219, qui la présentait comme une réponse distincte à une question plus large. La RFC 2782 a ensuite remplacé la RFC 2052 et décrit un enregistrement associant service, protocole, priorité, poids, port et cible. Son usage dépend toutefois d’une spécification applicative qui indique au client de l’interroger. La norme ultérieure ne transforme pas rétroactivement www en certificat d’enregistrement d’un service.

La contribution de la RFC 2219 était plus modeste et plus solide : un nom reconnaissable peut rendre une intention plus facile à trouver et un hôte plus facile à remplacer. Elle ne revendique pas l’autorité sur ce qui se trouve à l’autre bout. L’administrateur de la zone publie un indice ; l’opérateur de l’hôte contrôle l’écoute ; le client doit encore se connecter et interpréter la réponse. La porte symbolique peut bouger. Savoir si quelqu’un répond demeure une question opérationnelle.

Sources : RFC 2219 ; notice RFC Editor de la RFC 2219 ; IETF Datatracker : BCP 17 ; RFC 1912 ; RFC 1034 ; RFC 1035 ; RFC 2052 ; RFC 2782 ; RFC 1123.