Может ли (доменное имя) поддомены иметь подчеркивание "" в нем?

примечание по терминологии, в дополнение к ответу Бортцмейера

нужно четко понимать определения. Как используется здесь:

• доменное имя - это идентификатор ресурса в базе данных DNS
• label и часть доменного имени между точками
• хоста это специальный тип доменного имени, который идентифицирует интернет хозяева

The хоста подпадает под ограничения RFC 952 и небольшое расслабление RFC 1123

RFC 2181 дает понять, что есть разница между доменным именем и именем хоста:

...[тот факт, что] любая двоичная метка может иметь запись MX, не означает, что любое двоичное имя может использоваться в качестве основной части электронной почты адрес...

так подчеркивает в хоста нет-нет, подчеркивания в доменные имена - это-ок.

на практике вполне можно увидеть хоста С подчеркивания. Как то Принцип Робастности говорит:"Будьте консервативны в том, что вы посылаете, либеральны в том, что вы принимаете".

примечание по кодировке

в 21 веке, получается, что хоста а также доменные имена может быть интернациональными! Это означает обращение к кодировкам в случае метки, которые содержат символы, которые находятся за пределами допустимого набора.

в частности, он позволяет кодировать _ на хоста (обновление 2017-07: это сомнительно, см. комментарии. Элемент _ по-прежнему не может использоваться в именах хостов. В самом деле, он даже не может быть использован в интернационализированных этикетках.)

первый RFC для интернационализации был RFC 3490 от марта 2003 года, " интернационализация доменных имен в приложениях (IDNA)". Сегодня у нас есть:

• RFC 5890 "IDNA: определения и рамки документов"
• RFC 5891 "IDNA: протокол"
• RFC 5892 "кодовые точки Юникода и IDNA"
• RFC 5893 "Скрипты справа налево для IDNA"
• RFC 5894 "идна: Предыстория, объяснение и обоснование"
• RFC 5895 "отображение символов для IDNA 2008"

вы также можете проверить Запись В Википедии

RFC 5890 вводит термин LDH (Letter-Digit-Hypen) label на метки в хоста и говорит:

Это классическая форма меток, хотя и с некоторыми дополнительными ограничения, в именах хостов (RFC 952). Его синтаксис идентичен тому, что описано как" синтаксис предпочтительного имени " в разделе 3.5 RFC 1034 как изменено RFC 1123. Короче говоря, это строка, состоящая из букв ASCII, цифр и дефиса с дальнейшим ограничением, что дефис не может появиться в начале или конце строки. Как и все DNS-метки, его общая длина не должна превышать 63 октета.

возвращаясь к более простым временам,этот интернет-проект это раннее предложение для хоста интернационализации. Имена хостов с международными символами могут быть закодированы с использованием, например,'RACE' encoding.

автор предложения "RACE encoding" отмечает:

согласно RFC 1035, основные части должны быть нечувствительны к регистру, начинаться и заканчиваться буквой или цифрой и содержать только буквы, цифры и символ дефиса ("-"). Это, конечно, исключает любые интернационализированные персонажи, а также многие другие персонажи в репертуаре символов ASCII. Кроме того, части доменного имени должны быть 63 октета или короче длина.... Все после конвертированы названия деталей, которые содержат многоязычных символов начинается со строки "--БК". (...) Строку "БК" был выбран потому, что это крайне маловероятно существовать в частях хозяина прежде чем эта спецификация была произведена.

есть еще одна вещь, которую вам может понадобиться знать: если хост или часть поддомена url содержат подчеркивание, IE9 (не тестировали другие версии) не может писать куки.

Так что будьте осторожны. : -)

уточнение bortzmeyer и Дэвид Тонхофер, доменное имя и имя поддомена метки могут содержать ведущие подчеркивания, но нигде больше.

Как Дэвид Тонхофер написал, метки являются частями между периодами и должны следовать правилу LDH за исключением при указании меток служб и портов, чтобы отличить их от обычных меток. Затем они должны произойти в начале метки, которая должна быть " короткой Имена" от имя службы и номер порта в реестре, номер порта без ведущих 0s, или протокол (т. е. tcp, udp). Эти метки обслуживания дополнительно ограничены 15 символами.

• RFC2782 задает префикс поддомены записей службы с подчеркиванием.
• RFC6698 задает префикс номера портов с подчеркиванием в записях сертификата TLSA.

вопреки Давид Тонхофер's ответ, IDN не позволяет кодировать подчеркивание ('_'U+005F LOW LINE) или любой другой недопустимый символ ASCII.

С RFC5890

[..] два новых подмножества меток LDH создаются введение ИДНЫ. Это так называемые зарезервированные метки ЛДГ (Р-ЛДГ этикетки) и незарезервированных ЛДГ этикетки (НР-ЛДГ этикетки). Защищены ЛДГ метки, известные как" помеченные доменные имена " в некоторых других контекстах, имеют свойство, что они содержать "--" в третьем и четвертом персонажи но которые в противном случае соответствуют правилам метки LDH.

Punycode кодирует все кодовые точки ASCII как ASCII напрямую, включая подчеркивание. Полученный R-LDH не будет соответствовать правилам метки LDH. Например, Σ_.com будет закодировано как xn--_-zmb.com что нарушает правила. Причин может быть гомологического кода, который выглядит как подчеркивание, могут быть закодированы юридически (возможно＿' у+низкая линия FF3F полноширинный ), но эти виды кодовых точек будут классифицированы как запрещенные RFC5892 под 2.3 IgnorableProperties как Noncharacter_Code_Point.

RACE (другая предложенная схема кодирования IDN) не была принята IETF в качестве стандарта и не должна использоваться.

я перешел по ссылке на RFC1034 и прочитал большую его часть и был удивлен, увидев это:

метки должны соответствовать правилам для имен узлов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и в качестве межкомнатных символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Метки должны содержать не более 63 символов.

для уточнения, доменные имена состоят из меток, разделенных точками ".". Эта спецификация должна быть устаревшей, потому что в ней не упоминается использование подчеркиваний. Я могу понять путаницу, если кто-то спотыкается об эту спецификацию, не зная, что она устарела. Он устарел, не так ли?

я перешел по ссылке на RFC2181 и прочитал некоторые из них. Особенно там, где это относится к вопросу о том, что является авторитетным или каноническим именем и вопросом о том, что делает действительную метку DNS.

Как было опубликовано ранее, в нем говорится, что есть только ограничение длины подводя итог, он гласит:

(об именах и допустимых метках)

Они уже достаточно определены, однако спецификации, похоже, иногда игнорируются. Мы стремимся укрепить существующие спецификации.

вид оставляет мне интересно, если "длина только ограничение"является " адекватным". Мы собираемся начать видеть доменные имена типа @#$%!! скоро? Разве интернет недостаточно испорчен?

вот мои 2 цента из Java world:

из консоли Spark Scala, с 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

Это определенно плохая идея ^^

нет, если вы хотите его решить в Интернете.

вы не можете иметь:http://my_subdomain.somedomainname.com недопустимо.

вы можете иметь:http://my-subdomain.somedomainname.com с дефисом.