Résumé

  • La RFC 1123 autorisa un chiffre au début d’un nom d’hôte ; la RFC 1178 déconseilla pourtant ce choix, car des logiciels existants pouvaient confondre une chaîne numérique avec une adresse.
  • Pour la RFC 1178, le nom était une étiquette arbitraire : le rattacher à une personne, un projet, un lieu ou une fonction rendait l’étiquette ambiguë dès que l’organisation changeait.
  • La validité du libellé ne prouvait ni la branche choisie par le programme, ni le domaine local ajouté, ni la réponse DNS, ni l’identité du système, ni la migration de toutes les dépendances après un renommage.

Le droit d’accepter n’était pas un conseil de nommage

La RFC 1178, publiée en août 1990 comme FYI 5, se présente comme un texte d’information et non comme une norme. Elle republie un essai antérieur. Son dossier RFC Editor et sa fiche Datatracker fixent l’auteur, la date et le statut ; ils ne transforment pas les anecdotes du texte en rapports d’incident.

Quelques mois auparavant, la RFC 1123 avait changé une règle de syntaxe. Le premier caractère d’un nom d’hôte pouvait désormais être une lettre ou un chiffre, et le logiciel d’un hôte devait accepter cette forme. La notice RFC Editor conserve cette obligation dans le standard Host Requirements.

La RFC 1178 recommande néanmoins d’éviter un chiffre initial. Certains programmes acceptaient à la même entrée soit un nom, soit une adresse Internet numérique, mais les distinguaient mal. Un mot composé uniquement de chiffres hexadécimaux pouvait soulever une difficulté voisine. Il n’y a pas contradiction : la norme définit la cible d’une mise en conformité ; le guide choisit une étiquette prudente dans un parc où les programmes n’évoluent pas ensemble.

Une chaîne conforme peut donc échouer avant toute requête DNS. L’application peut la classer comme adresse, appliquer son propre parseur ou la refuser. Pour comprendre un cas réel, il faut connaître le programme, sa version et la décision prise, pas seulement relire la grammaire.

Une étiquette de projet vieillissait avec le projet

La RFC 1178 ne traite pas le nom comme un résumé de la machine. Elle le présente plutôt comme une étiquette arbitraire. Une machine appelée d’après l’atelier ou le projet auquel elle est d’abord affectée paraît claire le premier jour. Puis une seconde machine arrive, les tâches se spécialisent et la première part vers un autre usage. Le nom descriptif devient trompeur ; ajouter 2 et 3 ne restaure pas sa vérité, cela fabrique une numérotation.

Employer le nom d’une personne crée une autre dépendance. Dans la parole, il faut préciser si l’on désigne l’humain ou l’ordinateur. Après un remplacement, un logiciel qui cherchait un périphérique ou une base sur l’ancienne machine peut retrouver le même nom sur la nouvelle et y projeter une capacité qui n’a jamais migré.

Le nom prouve alors tout au plus qu’une étiquette a été configurée ou publiée. Il ne prouve pas la fonction actuelle, le gardien, le matériel, le service ni la continuité de ces éléments. Ces propriétés demandent un inventaire et des observations séparés.

Le parseur précédait parfois le résolveur

La RFC 1123 demandait aussi qu’un utilisateur puisse entrer un nom de domaine d’hôte ou une adresse IP en notation décimale pointée. Le logiciel devait examiner la forme numérique avant de consulter le DNS. Cette séquence plaçait une décision d’interface en amont du système de noms.

La RFC 952 avait auparavant exigé une lettre initiale dans la table des hôtes du DoD. Sa notice signale aujourd’hui la mise à jour par la RFC 1123. L’élargissement de la syntaxe fut donc un événement précis ; la disparition de toutes les hypothèses anciennes dans les logiciels en fut un autre.

Pour un diagnostic, l’échelle de preuve commence par la saisie exacte. Viennent ensuite la classification nom/adresse, les règles de l’application, l’appel éventuel au résolveur, le type de ressource demandé, la réponse et le cache. La connexion et le résultat applicatif se trouvent encore plus loin.

Un nom court héritait du site qui le complétait

La RFC 1034 distingue le nom complet, qui atteint la racine, du nom relatif, que le logiciel local complète grâce à une origine ou une liste de recherche. Elle précise que l’interprétation à l’interface peut varier selon les réalisations. La notice RFC Editor n’indique évidemment pas quelle liste utilisait un poste donné.

RFC 1178 applique ce principe au courrier : un destinataire écrit sous la forme d’un seul mot peut recevoir le domaine local ou être interprété comme appartenant à un autre domaine. La destination effective dépend du texte et du contexte de résolution.

Le même libellé peut aussi être réutilisé sous deux parents DNS différents. La RFC 1034 impose l’unicité entre frères, pas dans toute l’arborescence. Un nom court n’est donc pas une identité mondiale. Même un nom absolu ne prouve pas une machine : un nœud associe des données typées, éventuellement aucune, et la réponse dépend du type demandé.

La facilité humaine avait sa propre discipline

Le conseil de rester bref ne remplace pas la limite protocolaire de 63 caractères. Il vise l’usage quotidien. Les orthographes fantaisistes compliquent une consigne orale et le travail en urgence. La casse ne peut pas porter une différence d’identité fiable. Un nom humiliant perturbe une démonstration. Un thème fini s’épuise quand le nombre de machines dépasse la liste choisie.

Ces considérations montrent le chemin réel d’un nom : conversation, ticket, commande, message, journal, alerte, étiquette physique. Une chaîne acceptable pour DNS peut encore produire une erreur à chacune de ces frontières.

Renommer revenait à chercher les copies cachées

La fin de RFC 1178 avertit que les références s’accumulent. Des logiciels obscurs retiennent l’ancien nom, des correspondants extérieurs continuent de l’utiliser et des supports de sauvegarde conservent une ancienne association entre l’étiquette et la machine.

RFC 952 décourageait les surnoms, sauf comme coexistence temporaire de l’ancien et du nouveau nom pendant une transition. L’alias facilitait le déplacement ; il ne démontrait pas que chaque dépendance avait changé.

Une preuve de renommage complet demande donc plusieurs événements : décision autorisée, publication, fonctionnement de l’alias, expiration des caches, migration des programmes et contrôles, diminution de l’usage ancien, responsabilité des exceptions et critère de retrait. RFC 1178 n’écrit pas cette procédure moderne. Il décrit la dette qui l’impose.

Sources