Les sous-domaines (nom de domaine) peuvent-ils comporter un trait de soulignement "_"?
Les sous-domaines (noms de domaine) peuvent-ils contenir un trait de soulignement _?
La plupart des réponses données ici sont false. 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 de nom" :
Le DNS lui-même n'impose qu'une seule restriction aux étiquettes particulières qui peut être utilisé pour identifier des enregistrements de ressources. Celui-là La restriction concerne la longueur de l'étiquette et l'intégralité du prénom. [...] Les implémentations des protocoles DNS ne doivent placer aucun restrictions sur les étiquettes pouvant être utilisées. En particulier, DNS les serveurs ne doivent pas refuser de desservir une zone car elle contient des étiquettes cela pourrait ne pas être acceptable pour certains programmes client DNS.
Voir aussi la spécification DNS originale, RFC 1034 , section 3.5 "Syntaxe de nom préféré", mais lisez-la attentivement.
Les domaines avec des traits de soulignement sont très courants dans la nature. Vérifiez _Jabber._tcp.gmail.com ou _sip._udp.apnic.net.
Les autres RFC mentionnés ici traitent de choses différentes. La question Originale concernait noms de domaine. Si la question concerne Host Names (ou des URL qui incluent un nom d’hôte), il s'agit alors de Différent, la norme applicable est RFC 1123 , section 2.1 "Host Names and Numbers "qui limite noms d’hôte à Lettres-digits-hyphen.
Note sur la terminologie, dans le prolongement de la réponse de Bortzmeyer
Il faut être clair sur les définitions. Tel qu'utilisé ici:
- nom de domaine est l'identifiant d'une ressource dans une base de données DNS
- label est la partie d'un nom de domaine située entre des points
- nomhôte est un type spécial de nom de domaine qui identifie les hôtes Internet .
Le nom d'hôte est soumis aux restrictions de RFC 952 et de légère relaxation de RFC 1123
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 que tout nom binaire puisse être utilisé comme partie hôte d'une adresse électronique ...
Ainsi, les caractères de soulignement dans les noms d'hôtes sont non-non, les soulignements dans les noms de domaine sont a-ok.
En pratique, on peut voir les noms d’hôtes avec des traits de soulignement. Comme le Robustness Principle ==: "Soyez prudent dans ce que vous envoyez, libéral dans ce que vous acceptez".
Une note sur l'encodage
Au 21ème siècle, il s'avère que les noms d'hôte ainsi que les noms de domaine peuvent être internationalisés! Cela implique de recourir à des codages dans le cas d'étiquettes contenant des caractères ne faisant pas partie de l'ensemble autorisé.
En particulier, il permet de coder le _ dans noms d'hôtes (Mise à jour 2017-07: c'est douteux, voir les commentaires. Le _ ne peut toujours pas être utilisé dans En fait, il ne peut même pas être utilisé dans des étiquettes internationalisées.)
La première RFC pour l’internationalisation était RFC 3490 de mars 2003, "Internationalizing Domain Names in Applications (IDNA)". Aujourd'hui nous avons:
- RFC 5890 "IDNA: Définitions et structure de document"
- RFC 5891 "IDNA: Protocole"
- RFC 5892 "Les points de code Unicode et IDNA"
- RFC 5893 "Scripts de droite à gauche pour IDNA"
- RFC 5894 "IDNA: Contexte, explication et justification"
- RFC 5895 "Caractères de mappage pour IDNA 2008"
Vous pouvez aussi vouloir vérifier le Wikipedia Entry
RFC 5890 introduit le terme étiquette LDH (Letter-Digit-Hypen) pour étiquette utilisé dans les noms d’hôtes et dit:
C'est la forme d'étiquette classique utilisée, avec quelques restrictions supplémentaires, dans les noms d'hôte (RFC 952). Sa syntaxe est identique à celle décrite comme "syntaxe de nom préféré" dans la Section 3.5 de la RFC 1034 modifiée par la RFC 1123. En bref, il s'agit d'une chaîne composée de ASCII lettres, de chiffres et du trait d'union avec restriction supplémentaire que le trait d'union ne peut pas apparaître 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 brouillon Internet est une première proposition d'internationalisation du nom d'hôte . Les noms d’hôte avec des caractères internationaux peuvent être encodés en utilisant, par exemple, 'encodage' RACE ' .
L'auteur de la proposition 'RACE encoding' 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 ne contenir que des lettres, des chiffres et le trait d'union ("-"). Ceci, bien sûr, exclut tous les caractères internationalisés, ainsi que de nombreux autres caractères du répertoire de caractères ASCII. De plus, les parties de nom de domaine doivent avoir une longueur maximale de 63 octets .... Toutes les parties de nom converties après conversion 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 improbable qu'elle existe dans les parties hôte avant la production de cette spécification.
Il se peut que vous ayez à savoir une chose supplémentaire: si l'hôte ou une partie de l'URL contenant un sous-domaine contient un trait de soulignement, IE9 (n'ayant pas testé d'autres versions) ne peut pas enregistrer de cookies.
Alors faites attention à cela. :-)
Clarifier bortzmeyer et David Tonhofer , Les étiquettes de noms de domaine et de noms de sous-domaines peuvent contenir des traits de soulignement importants, mais nulle part ailleurs.
Comme David Tonhofer écrivait, les étiquettes sont les parties intermédiaires et doivent respecter la règle LDH sauf lors de la spécification des étiquettes de service et des étiquettes de port afin de les différencier des étiquettes classiques. Ensuite, ils doivent apparaître au début de l’étiquette, c’est-à-dire les "noms abrégés" de Nom du service et registre du numéro de port , le numéro de port sans 0, ou le protocole (par exemple. Tcp, udp). Ces étiquettes de service sont en outre limitées à 15 caractères.
- RFC2782 spécifie le préfixe Sous-domaines d'enregistrement de service avec des traits de soulignement.
- RFC6698 spécifie le préfixe des numéros de port Avec des traits de soulignement dans les enregistrements de certificat TLSA.
Contrairement à la réponse de David Tonhofer , IDN ne permet pas d’encoder le trait de soulignement ('_' U + 005F LOW LINE) ni aucun autre caractère non valide ASCII.
De RFC5890
[..] Deux nouveaux sous-ensembles d'étiquettes LDH sont créés par le fichier 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). LDH réservé Les étiquettes, appelées "noms de domaine marqués" dans d'autres contextes, ont la propriété qu'ils contiennent "-" dans les troisième et quatrième caractères mais qui sont conformes aux règles d'étiquette LDH.
Punycode code tous les points de codage ASCII directement sous forme de ASCII, y compris le trait de soulignement. Le R-LDH résultant ne serait pas conforme aux règles d'étiquette LDH. Par exemple, Σ_.com serait codé en tant que xn--_-zmb.com, ce qui violerait 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 '＿' U + FF3F en bas de ligne pleine largeur), mais ces types de points de code seraient classés dans la catégorie RETIRÉ par 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 la RFC1034 et en ai lu l'essentiel, et j'ai été surpris de voir ceci:
Les étiquettes doivent suivre les règles pour les noms d'hôte ARPANET. Ils doivent commencer par une lettre, se terminer par une lettre ou un chiffre et avoir comme intérieur Caractères uniquement des lettres, des chiffres et un trait d'union. Il existe également des restrictions de Sur la longueur. Les étiquettes doivent comporter 63 caractères ou moins.
Pour plus de clarté, un nom de domaine est constitué d'étiquettes séparées par des points ".". Cette spécification doit être obsolète car elle ne mentionne pas l'utilisation de traits de soulignement. Je peux comprendre la confusion si quelqu'un trébuche sur cette spécification sans savoir qu'elle est obsolète. C'est obsolète, n'est-ce pas?
J'ai suivi le lien vers la RFC2181 et en ai lu une partie. Surtout quand il s'agit de la question de savoir ce qui est un nom faisant autorité, ou canonique, et de la question de savoir ce qui constitue une étiquette DNS valide.
Comme indiqué précédemment, il est indiqué qu'il n'y a qu'une restriction de longueur. Pour résumer, lisez ce qui suit:
(sur les noms et les étiquettes valides)
Celles-ci sont déjà bien spécifiées, mais les spécifications semblent parfois être ignorées. Nous cherchons à renforcer les spécifications existantes.
En quelque sorte, je me demande 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 foutu?
Voici mes 2 centimes 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 ^^
Récemment, le forum CAB (*) a décidé que
Tous les certificats contenant un caractère de soulignement dans une 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 dotés d'un certificat ssl/tls.
(*) Le forum du navigateur des autorités de certification (CA/Browser Forum) est un regroupement volontaire des principaux émetteurs de certificats (définis à la section 2.1 (a) (1) et (2) ci-dessous) et des fournisseurs de logiciels de navigation Internet et autres applications qui: utiliser des certificats (utilisateurs de certificats, tels que définis dans la section 2.1 (a) (3) ci-dessous).