Les sous-domaines (noms de domaine) peuvent-ils contenir un trait _de soulignement ?
Réponses:
La plupart des réponses données ici sont fausses . Il est parfaitement légal d'avoir un trait de soulignement dans un nom de domaine. Permettez-moi de citer la norme, RFC 2181, section 11, "Syntaxe des noms" :
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. [...] Les implémentations des protocoles DNS ne doivent imposer aucune restriction sur les labels qui peuvent être utilisés. En particulier, les serveurs DNS ne doivent pas refuser de desservir une zone car elle contient des étiquettes qui pourraient ne pas être acceptées par certains programmes clients DNS.
Voir également la spécification DNS d'origine, RFC 1034 , section 3.5 "Syntaxe de nom préférée" mais lisez-la attentivement.
Les domaines avec des traits de soulignement sont très communs dans la nature. Vérifiez _jabber._tcp.gmail.comou_sip._udp.apnic.net .
Les autres RFC mentionnés ici traitent de différentes choses. La question initiale concernait les noms de domaine . Si la question concerne les noms d'hôte (ou les URL, qui incluent un nom d'hôte), alors c'est différent, la norme pertinente est RFC 1123 , section 2.1 "Noms et numéros d' hôte " qui limite les noms d'hôte à lettres-chiffres-trait d'union.
_jabber._tcp.gmail.comn'est pas un domaine, c'est un FQDN. Étant donné que les URL ne peuvent pas contenir de trait de soulignement, vous ne pourrez probablement jamais acheter un domaine contenant un trait de soulignement. Ainsi, même les domaines peuvent également avoir des traits de soulignement du point de vue de la syntaxe DNS, vous n'en rencontrerez jamais, sauf s'il s'agit d'un domaine local.
Il faut être clair sur les définitions. Tel qu'utilisé ici:
Le nom d'hôte est soumis aux restrictions de la RFC 952 et à la légère relaxation de la RFC 1123
La RFC 2181 indique clairement qu'il existe une différence entre un nom de domaine et un nom d'hôte:
... [le fait que] n'importe quelle étiquette binaire puisse avoir un enregistrement MX n'implique pas qu'un nom binaire puisse être utilisé comme partie hôte d'une adresse e-mail ...
Donc, les traits de soulignement dans les noms d'hôtes sont un non-non, les traits de soulignement dans les noms de domaine sont a-ok.
Dans la pratique, on peut très bien voir des noms d' hôtes avec des traits de soulignement. Comme principe de robustesse dit le : "Soyez conservateur dans ce que vous envoyez, libéral dans ce que vous acceptez".
Au 21e siècle, il s'avère que les noms d' hôte ainsi que les noms de domaine peuvent être internationalisés! Cela signifie recourir à des encodages en cas d' étiquettes contenant des caractères qui se trouvent en dehors de l'ensemble autorisé.
En particulier, il permet de coder les _dans hostname (Mise à jour 2017-07. Ceci est douteux, voir les commentaires Le_ .. Ne peut toujours pas être utilisé dans hostnames En effet, il ne peut même être utilisé dans des étiquettes internationalisés)
Le premier RFC pour l'internationalisation a été le RFC 3490 de mars 2003, "Internationalisation des noms de domaine dans les applications (IDNA)". Aujourd'hui nous avons:
Vous pouvez également vérifier l'entrée Wikipedia
La RFC 5890 introduit le terme étiquette LDH (Letter-Digit-Hypen) pour les étiquettes utilisées dans les noms d'hôtes et dit:
Il s'agit de la forme d'étiquette classique utilisée, bien qu'avec quelques restrictions supplémentaires, dans les noms d'hôte (RFC 952). Sa syntaxe est identique à celle décrite comme la "syntaxe de nom préférée" dans la section 3.5 de la RFC 1034 telle que modifiée par la RFC 1123. En bref, il s'agit d'une chaîne composée de lettres ASCII, de chiffres et du trait d'union avec la restriction supplémentaire que le trait d'union ne peut pas apparaissent au début ou à la fin de la chaîne. Comme toutes les étiquettes DNS, sa longueur totale ne doit pas dépasser 63 octets.
Pour revenir à des temps plus simples, ce projet Internet est une première proposition pour l' internationalisation du nom d' hôte . Les noms d'hôtes avec des caractères internationaux peuvent être encodés en utilisant, par exemple, l'encodage 'RACE' .
L'auteur de la proposition «Encodage RACE» note:
Selon la RFC 1035, les parties hôtes doivent être insensibles à la casse, commencer et se terminer par une lettre ou un chiffre, et contenir uniquement des lettres, des chiffres et le trait d'union ("-"). Bien entendu, cela exclut tout caractère internationalisé, ainsi que de nombreux autres caractères du répertoire de caractères ASCII. De plus, les parties de nom de domaine doivent être de 63 octets ou de longueur plus courte .... Toutes les parties de nom post-converties qui contiennent des caractères internationalisés commencent par la chaîne "bq--". (...) La chaîne "bq--" a été choisie car il est extrêmement peu probable qu'elle existe dans les parties hôtes avant la production de cette spécification.
bar.baz.(par exemple) n'est que la collection de noms de domaine qui sont hiérarchiquement en dessousbar.baz. , par exemple a.bar.baz., f.g.bar.baz., h.bar.baz., etc. Ce "sous-domaine" peut ou non inclure des noms d'hôtes réels .
a.bar.baz(un nom de domaine) "un sous-domaine de" la chaîne bar.baz(un autre nom de domaine). Les noms de domaine (ressources de base de données DNS) a.bar.bazet bar.bazpeuvent ou non être des noms d'hôte .
Il y a une chose supplémentaire que vous devez savoir: si la partie hôte ou sous-domaine de l'URL contient un trait de soulignement, IE9 (n'a pas testé d'autres versions) ne peut pas écrire de cookies.
Soyez donc prudent à ce sujet. :-)
Clarifier Bortzmeyer et David Tonhofer , les étiquettes de nom de domaine et de nom de sous-domaine peuvent contenir des soulignements principaux, mais nulle part ailleurs.
Comme David Tonhofer l'a écrit, les étiquettes sont les parties entre les périodes et doivent suivre la règle LDH, sauf lors de la spécification des étiquettes de service et des étiquettes de port pour les différencier des étiquettes normales. Ensuite, ils doivent apparaître au début de l'étiquette, qui doit être les «noms courts» du registre des noms de service et des numéros de port , le numéro de port sans 0 en tête ou le protocole (c.-à-d. Tcp, udp). Ces étiquettes de service sont en outre limitées à 15 caractères.
Contrairement à David Tonhofer , l'IDN ne permet pas d'encoder le soulignement ('_' U + 005F LOW LINE) ou tout autre caractère ASCII invalide.
Depuis RFC5890
[..] deux nouveaux sous-ensembles d'étiquettes LDH sont créés par l'introduction d'IDNA. Celles-ci sont appelées étiquettes LDH réservées (étiquettes R-LDH) et étiquettes LDH non réservées (étiquettes NR-LDH). Les étiquettes LDH réservées, appelées "noms de domaine marqués" dans certains autres contextes, ont la propriété qu'elles contiennent "-" dans les troisième et quatrième caractères mais qui autrement sont conformes aux règles d'étiquette LDH .
Punycode code directement tous les points de code ASCII en ASCII, y compris le trait de soulignement. Le R-LDH résultant ne serait pas conforme aux règles d'étiquette LDH. Par exemple, Σ_.comserait codé comme xn--_-zmb.comviolant les règles. Il peut y avoir un point de code homographique qui ressemble à un trait de soulignement qui peut être codé légalement (peut-être la ligne basse pleine largeur U + FF3F), mais ces types de points de code seraient classés comme INTERDITS par la RFC5892 sous 2.3 IgnorableProperties en tant que Noncharacter_Code_Point.
RACE (l'autre schéma de codage IDN proposé) n'a pas été accepté comme norme par l'IETF et ne doit pas être utilisé.
J'ai suivi le lien vers RFC1034 et en ai lu la plupart et j'ai été surpris de voir ceci:
Les étiquettes doivent suivre les règles des noms d'hôte ARPANET. Ils doivent commencer par une lettre, se terminer par une lettre ou un chiffre et avoir comme caractères intérieurs uniquement des lettres, des chiffres et un trait d'union. Il existe également des restrictions sur la longueur. Les étiquettes doivent contenir 63 caractères ou moins.
Pour plus de précision, un nom de domaine est composé d'étiquettes séparées par des points ".". Cette spécification doit être obsolète car elle ne mentionne pas l'utilisation de soulignements. Je peux comprendre la confusion si quelqu'un bute sur cette spécification sans savoir qu'elle est obsolète. C'est obsolète, non?
J'ai suivi le lien vers RFC2181 et en ai lu une partie. Surtout lorsqu'il s'agit de la question de savoir ce qu'est un nom faisant autorité ou canonique et de ce qui fait une étiquette DNS valide.
Comme indiqué précédemment, il indique qu'il n'y a qu'une restriction de longueur, puis pour résumer, il indique:
(sur les noms et les étiquettes valides)
Ceux-ci sont déjà correctement spécifiés, mais les spécifications semblent parfois être ignorées. Nous cherchons à renforcer les spécifications existantes.
Je me demande en quelque sorte si "une restriction de longueur seulement" est "adéquate". Allons-nous commencer à voir des noms de domaine comme @ # $% !! bientôt? Internet n'est-il pas assez vissé?
Récemment, le CAB-forum (*) a décidé que
Tous les certificats contenant un caractère de soulignement dans toute entrée dNSName et ayant une période de validité de plus de 30 jours DOIVENT être révoqués avant le 15 janvier 2019. https://cabforum.org/2018/11/12/ballot-sc-12- sunset-of-underscores-in-dnsnames /
Cela signifie que vous n'êtes plus autorisé à utiliser des traits de soulignement dans les domaines qui auront un certificat ssl / tls.
(*) Le Forum des navigateurs de l'autorité de certification (CA / Browser Forum) est un rassemblement volontaire des principaux émetteurs de certificats (tels que définis à la section 2.1 (a) (1) et (2) ci-dessous) et des fournisseurs de logiciels de navigation Internet et d'autres applications qui utiliser des certificats (consommateurs de certificats, tels que définis à la section 2.1 (a) (3) ci-dessous).
Les TLD individuels peuvent placer leurs propres règles et restrictions sur les noms de domaine comme bon leur semble, par exemple pour s'adapter aux langues locales.
Par exemple, selon l' ACEI , les .canoms de domaine du Canada sont autorisés:
Lettres à
atraversz, et les caractères accentués suivants:é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Notez que les noms de domaine ne sont pas sensibles à la casse. Cela signifie qu'il n'y aura pas de distinction entre les majuscules et les minuscules (A=a);Les chiffres
0123456789, etLe trait d'union ("
-) (bien qu'il ne puisse pas être utilisé pour démarrer ou terminer un nom de domaine).
La longueur maximale est de 63 caractères, sauf que chaque caractère accentué réduit cette limite de 4 caractères.
( Source )
Soit dit en passant , cela permet environ 4 quadragintillions possibilités de nom de domaine (sans compter les sous-domaines) pour les domaines point-ca.
Voici mes 2 cents du monde Java:
Depuis une console Spark Scala, avec Java 8:
scala> new java.net.URI("spark://spark_master").getHost
res10: String = null
scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master
scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null
scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr
scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr
scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null
C'est définitivement une mauvaise idée ^^
Je viens de créer un projet local (avec vagabond) et cela fonctionnait parfaitement lorsqu'il était accessible via l'adresse IP. Ensuite, j'ai ajouté some_name.test au fichier hosts et j'ai essayé d'y accéder de cette façon, mais je recevais tout le temps une "mauvaise demande - 400". Des heures perdues jusqu'à ce que je comprenne que le simple changement de nom de domaine en some-name.test résout le problème. Donc, au moins localement sur Mac OS, cela ne fonctionne pas.
Non, vous ne pouvez pas utiliser de soulignement dans le sous-domaine, mais l'hypen (tiret). ie my-subdomain.agahost.com est acceptable et my_subdomain.agahost.com ne serait pas acceptable.
Pas si vous voulez le résoudre sur Internet.
Vous ne pouvez pas avoir: http://my_subdomain.example.com n'est pas valide.
Vous pouvez avoir: http://my-subdomain.example.com avec un trait d'union.