Peut (nom de domaine) sous-domaines ont un caractère de soulignement " "?

Une note sur la terminologie, dans la poursuite de Bortzmeier la réponse de

les définitions doivent être claires. Tel qu'il est utilisé ici:

• nom de domaine est le identifiant d'une ressource dans une base de données DNS
• étiquette est la partie d'un nom de domaine entre les points
• nom d'hô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 le léger assouplissement de RFC 1123

RFC 2181 indique clairement qu'il y a une différence entre un nom de domaine et un nom d'hôte:

...[le fait que] n'importe quelle étiquette binaire peut avoir un enregistrement MX ne signifie pas que n'importe quel nom binaire peut être utilisé comme la partie hôte d'une adresse e-mail...

si souligne dans nom d'hôte sont un non-non, souligne dans noms de domaine sont A-ok.

dans la pratique, on peut bien voir nom d'hôte avec des underscores. Comme le principe de Robustesse dit: "soyez prudent dans ce que vous envoyez, libéral dans ce que vous acceptez".

Une note sur le codage de la

au 21ème siècle, il s'avère que hôtes ainsi que noms de domaine peut être internationalisé! Cela signifie recourir à des encodages dans le cas de étiquettes qui contiennent des caractères qui sont en dehors de l'ensemble autorisé.

en particulier, il permet d'encoder le _ dans nom d'hôte (mise à jour 2017-07: c'est douteux, voir les commentaires. Le _ ne peut toujours pas être utilisé dans les noms d'hôtes. En effet, il ne peut même pas être utilisé dans internationalisés étiquettes.)

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 Cadre des documents d'"
• RFC 5891 "IDNA: protocole "
• RFC 5892 "the Unicode Code Points and IDNA "
• RFC 5893 et "Droite-à-Gauche des Scripts pour IDNA"
• RFC 5894 "IDNA: Contexte, l'Explication et la Justification"
• RFC 5895 "Mappage de Caractères pour IDNA 2008"

vous pouvez également consulter la entrée Wikipédia

RFC 5890 introduit le terme LDH (Letter-Digit-Hypen) étiquette pour étiquettes utilisé dans noms d'hôtes et dit:

c'est la forme d'étiquette classique utilisée, bien que avec quelques restrictions supplémentaires, dans les noms d'hôtes (RFC 952). Sa syntaxe est identique à celle décrite comme la "syntaxe du nom préféré" 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 de caractères 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 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.

retour aux temps plus simples, ce projet Internet est un début de proposition pour nom d'hôte l'internationalisation. Les noms d'hôtes avec des caractères internationaux peuvent être encodés en utilisant, par exemple, "RACE" encodage .

l'auteur de La " COURSE de codage de proposition des notes:

selon la RFC 1035, les pièces de l'hôte doivent être insensibles à la casse, commencer et se terminer par une lettre ou un chiffre, et ne contenir que des lettres., les chiffres et le tiret ("-"). Cela exclut évidemment tout personnage internationalisé, ainsi que de nombreux autres personnages du répertoire ASCII. De plus, les parties d'un nom de domaine doivent être de 63 octets ou plus courtes en longueur.... Toutes les parties de noms post-converties qui contiennent des caractères internationalisés commencent par la chaîne de caractères "bq--". (...) La chaîne "bq--" a été choisie parce qu'elle est extrêmement improbable pour exister dans les pièces hôtes avant que cette spécification a été produite.

il y a une autre chose que vous devez savoir: si la partie hôte ou sous-domaine de l'url contient un underscore, IE9 (n'a pas testé d'autres versions) ne peut pas écrire de cookies.

alors faites attention. :- )

Clarifier bortzmeyer et David Tonhofer , nom de domaine et le nom de sous-domaine étiquettes peuvent contenir des principaux traits de soulignement, mais nulle part ailleurs.

comme David Tonhofer écrit, les étiquettes sont les parties entre les périodes et doivent suivre la règle LDH sauf en spécifiant des étiquettes de service et des étiquettes de port pour les différencier des étiquettes régulières. Alors ils doivent se produire à le début de l'étiquette qui doit être les "noms abrégés" du nom de Service et numéro de Port Registre , le numéro de port sans 0, ou le protocole (c.-à-d. tcp, udp). Ces étiquettes sont limités à 15 caractères.

• RFC2782 spécifie le préfixe sous-domaines de service avec underscores.
• RFC6698 spécifie le préfixe port les numéros avec des caractères soulignés dans les enregistrements de certificats TLSA.

contrairement à David Tonhofer 's answer, IDN ne permet pas d'encoder le caractère underscore ('_' U+005F LOW LINE) ou tout autre caractère ASCII invalide.

de RFC5890

[..] deux nouveaux sous-ensembles d'étiquettes LDH sont créés par la introduction de L'IDNA. Ces étiquettes sont appelées étiquettes LDH réservées (R-LDH labels) et les labels LDH Non réservés (labels NR-LDH). Réservé la LDH les étiquettes, connu comme "noms de domaine marqués" dans d'autres contextes, ont la propriété qu'ils contiennent "--" dans la troisième et la quatrième caractères , mais qui sont conformes aux règles de l'étiquette LDH .

Punycode code tous les codépoints ASCII comme ASCII directement, y compris les underscore. La R-LDH résultante ne serait pas conforme aux règles d'étiquetage de la LDH. Par exemple, Σ_.com serait codé comme xn--_-zmb.com ce qui viole les règles. Il peut y avoir un codepoint homographique qui ressemble à un underscore qui peut être codé légalement (peut-être une ligne "end" U+FF3F pleine largeur), mais ces types de codepoints seraient classés comme rejetés par RFC5892 sous 2.3 Propositions ignorables comme un Noncharacter_Code_Point.

RACE (l'autre schéma d'encodage IDN proposé) n'a pas été accepté comme norme par L'IETF et ne devrait pas être utilisé.

j'ai suivi le lien vers RFC1034 et j'en ai lu la plupart et j'ai été surpris de voir cela:

les étiquettes doivent respecter les règles pour les noms D'hôtes ARPANET. Ils doivent commencer par une lettre, se terminent par une lettre ou un chiffre, et ont de l'intérieur caractères seulement les lettres, les chiffres et le trait d'Union. Il y a aussi quelques restrictions sur la longueur. Les étiquettes doivent comporter 63 caractères ou moins.

pour plus de clarté, un nom de domaine est composé de les étiquettes qui sont séparés par des points ".". Cette spécification doit être périmée car elle ne mentionne pas l'utilisation de underscores. Je peux comprendre la confusion si quelqu'un trébuche sur cette spécification sans savoir qu'elle est obsolète. Il est obsolète, n'est-ce pas?

j'ai suivi le lien vers RFC2181 et j'en ai lu une partie. En particulier lorsqu'il s'agit de savoir ce qu'est un nom autorisé ou canonique et de savoir ce qui constitue une étiquette DNS valide.

Comme affiché plus tôt, il indique qu'il n'y a qu'une restriction de longueur, puis pour résumer, il se lit:

(au sujet des noms et des étiquettes valides)

ces spécifications sont déjà spécifiées de manière adéquate, mais elles semblent parfois ignorées. Nous cherchons à renforcer les normes existantes.

me laisse à me demander si "une seule restriction de longueur" est "adéquate". Allons-nous commencer à voir des noms de domaines comme @#$%!! bientôt? N'est-ce pas l'internet foiré assez?

Voici mes 2 cents de Java world:

d'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 certainement une mauvaise idée ^^

pas si vous voulez que ça se résolve sur Internet.

vous ne pouvez pas avoir: http://my_subdomain.somedomainname.com est invalide.

vous pouvez avoir: http://my-subdomain.somedomainname.com avec un trait d'Union.