Les noms d'hôtes à une lettre sont-ils valides?

La RFC-952 (dernière phrase du point 1 sous Hypothèses) interdit les noms d'hôte à caractère unique et j'ai eu des expériences (il y a plus de 7 ans à l' été 2002) où certains services refusaient de travailler avec des noms d'hôte à caractère unique (car ces noms étaient non conforme aux normes), mais j'ai vu un certain nombre de noms d'hôte à caractère unique utilisés au cours des dernières années. Les noms d'hôtes à un seul caractère sont-ils désormais valides? (Si oui, quelle est la référence de validation appropriée?)

modifier (pour consolider certaines informations des réponses): divers aspects du DNS semblent être définis dans plusieurs RFC, y compris 1035 , 1123 et 2181 . De la RFC-2181 section 11 :

Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment.  For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.

De RFC-1123 section 6.1.3.5 :

The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets.  Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names.  In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].

De RFC-1123 section 2.1 :

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4].  One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit.  Host software MUST support this more liberal
syntax.

Et enfin, comme à l'origine référencé, de la RFC-952 :

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.).  Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background).  No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case.  The first
character must be an alpha character.  The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.

C'est en suivant cette chaîne que je suis venu à l'origine pour dire que la RFC-952 interdit les noms d'hôte à un seul caractère.

Il y a une différence entre «valide» et «ça marche». Il est tout à fait possible que les noms d'hôte ne soient pas considérés comme valides s'ils sont des caractères uniques (mon article précédent ne résiste pas). Cependant, beaucoup de systèmes le permettent. Un système majeur, le système AD / DNS de Microsoft, a une raison ancienne pour autoriser les noms de caractère unique.

Les noms NetBIOS à l'ancienne peuvent contenir entre 1 et 15 caractères. Cette spécification a été développée indépendamment de RFC952, elle est basée sur un fichier différent appelé lmhosts, donc cela fonctionne. Le problème est survenu lorsque Microsoft a quitté NetBEUI (en fait NBF, NetBIOS Frame Protocol) et TCP / IP (en fait NBT), et Microsoft a dû autoriser la résolution de noms sur les réseaux TCP / IP. MS a choisi de maintenir la résolution de style NetBIOS avec les serveurs WINS, en contournant le besoin d'hôtes compatibles RFC952.

Vint ensuite Active Directory et ses dépendances DNS. Le DNS dynamique était la règle, les clients devaient donc enregistrer leur ComputerName (dont les 15 premiers caractères sont également leur nom NetBIOS) dans le domaine DNS. Étant donné que MS permet aux noms NetBIOS à un seul caractère de s'enregistrer dans DNS, cela l'a mis en conflit avec RFC952. Ils ont décidé de coder leurs systèmes pour permettre cela, car cela imitait comment cela fonctionnait toujours à l'époque WINS.

BIND DNS autorise également les noms d'hôte à un seul caractère. Mais le RFC2181 déclare à peu près que les applications doivent contrôler leurs propres données, et non plus DNS. Ce qui nous laisse avec une grande population d'appareils et de logiciels pour lesquels les noms d'hôte à un seul caractère sont très bien, et quelques valeurs aberrantes strictes RFC952 qui ne le permettent pas.

Vous penseriez qu'ils sont valides car les serveurs de noms racine sont tous des hôtes à lettre unique (a.root-servers.net), et la spécification DNS ne crée pas d'exception spécifique pour eux. Le RFC en question est spécifiquement pour le format de fichier hôte, pas DNS. Le DNS a été défini dans une RFC ultérieure ( RFC 1035 le démarre). La RFC 1123 (1989) le dit clairement.

 The syntax of a legal Internet host name was specified in RFC-952
 [DNS:4].  One aspect of host name syntax is hereby changed: the
 restriction on the first character is relaxed to allow either a
 letter or a digit.  Host software MUST support this more liberal
 syntax.

Ainsi, les noms d'hôte à lettre unique sont valides dans les systèmes basés sur DNS, et ce depuis bien avant que le spam ne soit inventé. Les systèmes qui ne le sont pas ne sont pas conformes à la RFC et peuvent se moquer. À moins qu'ils n'utilisent pas du tout DNS et n'utilisent que des fichiers hôtes, à quel point la pitié est un meilleur choix.

Comme les noms d'hôte étaient là avant que quiconque ne pense à écrire un RFC à leur sujet, je ne vois aucune raison pour laquelle les noms d'hôte à caractère unique devraient soudainement devenir "illégaux". Ce RFC particulier m'a perdu quand il a déclaré

Cette RFC est la spécification officielle

car un RFC n'est PAS une norme. Pas même près.

Malgré ce qui précède, il convient de noter que le RFC en question a été créé pour s'appliquer à un groupe relativement restreint, à savoir le Department of Defence (vraisemblablement des États-Unis).

Je pense que les noms d'hôte actuels dépendent davantage des spécifications DNS car le DNS est ce que la plupart des gens utiliseront à l'intérieur d'un réseau ou sur Internet. Dit que, trois RFC viennent à l'esprit (1034 - concepts, 1035 - implémentation et 2181 - clarifications sur DNS).

L'article 3 de la RFC 1034 dit:

L'espace de nom de domaine est une structure arborescente. Chaque nœud et feuille de l'arbre correspond à un ensemble de ressources (qui peut être vide). Le système de domaine ne fait aucune distinction entre les utilisations des nœuds intérieurs et des feuilles, et cette note utilise le terme «nœud» pour désigner les deux.

Chaque nœud a une étiquette, de zéro à 63 octets. Les nœuds frères peuvent ne pas avoir la même étiquette, bien que la même étiquette puisse être utilisée pour les nœuds qui ne sont pas frères. Une étiquette est réservée, et c'est l'étiquette nulle (c'est-à-dire de longueur nulle) utilisée pour la racine.

Et dans la section 11 de la RFC 2181, nous avons une clarification sur le nom de chaque nœud de l'adresse:

Le DNS lui-même ne place qu'une seule restriction sur les étiquettes particulières
qui peuvent être utilisées pour identifier les enregistrements de ressources. Cette seule restriction
concerne la longueur de l'étiquette et le nom complet. La longueur de n'importe quelle étiquette est limitée entre 1 et 63 octets. Un nom de domaine complet est limité à 255 octets (y compris les séparateurs)

Donc, à la lumière des spécifications DNS, vous pouvez avoir a.domain.tld

Comme vous l'avez déterminé, la RFC 1123 n'est pas complètement claire sur ce problème de longueur.

La section 2.1 dit:

Le logiciel hôte DOIT gérer les noms d'hôtes jusqu'à 63 caractères et DEVRAIT gérer les noms d'hôtes jusqu'à 255 caractères

Étant donné que ce texte remplace effectivement complètement le texte de la RFC 952, il doit également être considéré comme impliquant que toute longueur jusqu'à 255 caractères est légale.

Malheureusement, en 1989, Internet Drafts n'a pas reçu l'examen incroyablement rigoureux qu'ils reçoivent maintenant, de sorte que l'ambiguïté n'a probablement pas été repérée.