Могут ли субдомены (имя домена) иметь подчеркивание «_»?

Могут ли субдомены (доменные имена) иметь подчеркивание _в них?

Большинство ответов, приведенных здесь, являются ложными . Совершенно законно иметь подчеркивание в доменном имени. Позвольте мне процитировать стандарт, RFC 2181, раздел 11, «Синтаксис имени» :

Сам DNS накладывает только одно ограничение на конкретные метки, которые можно использовать для идентификации записей ресурсов. Это одно ограничение касается длины метки и полного имени. [...] Реализации протоколов DNS не должны накладывать каких-либо ограничений на метки, которые можно использовать. В частности, DNS-серверы не должны отказываться обслуживать зону, поскольку она содержит метки, которые могут быть неприемлемы для некоторых клиентских программ DNS.

См. Также оригинальную спецификацию DNS, RFC 1034 , раздел 3.5 «Предпочтительный синтаксис имени», но внимательно прочтите его.

Домены с подчеркиванием очень распространены в дикой природе. Проверьте_jabber._tcp.gmail.com или _sip._udp.apnic.net.

Другие упомянутые здесь RFC имеют дело с разными вещами. Первоначальный вопрос был для доменных имен . Если вопрос касается имен хостов (или URL-адресов, которые включают имя хоста), то это другой вопрос, соответствующий стандарт - RFC 1123 , раздел 2.1 «Имена и номера хостов», который ограничивает имена хостов букв-цифр-дефиса.

Записка по терминологии в поддержку ответа Борцмейера

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

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

На имя хоста распространяются ограничения RFC 952 и небольшое ослабление RFC 1123.

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

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

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

На практике хорошо видно имена хостов с подчеркиванием. Как гласит принцип робастности : «Будь консервативным в том, что ты посылаешь, либеральным в том, что ты принимаешь».

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

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

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

Первым RFC для интернационализации был RFC 3490 от марта 2003 года «Интернационализация доменных имен в приложениях (IDNA)». Сегодня у нас:

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

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

RFC 5890 вводит термин LDH (Letter-Digit-Hypen) для меток, используемых в именах хостов, и говорит:

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

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

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

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

Возможно, вам нужно знать еще одну вещь: если часть URL-адреса узла или субдомена содержит подчеркивание, IE9 (не проверял другие версии) не может записывать файлы cookie.

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

Разъясняющие bortzmeyer и David Tonhofer , метки доменного имени и имени субдомена могут содержать символы подчеркивания, но больше нигде.

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

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

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

От RFC5890

[..] два новых подмножества меток LDH создаются путем введения IDNA. Они называются зарезервированными метками LDH (метки R-LDH) и незарезервированными метками LDH (метки NR-LDH). Зарезервированные метки LDH, известные как «помеченные доменные имена» в некоторых других контекстах, имеют свойство, которое они содержат «-» в третьем и четвертом символах, но в остальном соответствуют правилам меток LDH .

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

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

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

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

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

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

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

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

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

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

Недавно CAB-форум (*) решил, что

Все сертификаты, содержащие символ подчеркивания в любой записи dNSName и имеющие срок действия более 30 дней, ДОЛЖНЫ быть аннулированы до 15 января 2019 года. Https://cabforum.org/2018/11/12/ballot-sc-12- закат-оф-подчеркивания-в-dnsnames /

Это означает, что вам больше не разрешено использовать подчеркивание в доменах, которые будут иметь сертификат ssl / tls.

(*) Форум браузеров Центра сертификации (CA / Browser Forum) - это добровольное собрание ведущих эмитентов сертификатов (как определено в разделе 2.1 (a) (1) и (2) ниже) и поставщиков программного обеспечения для интернет-браузера и других приложений, которые использовать сертификаты (потребители сертификатов, как определено в разделе 2.1 (а) (3) ниже).

Отдельные TLD могут устанавливать свои собственные правила и ограничения для доменных имен по своему усмотрению, например, для размещения местных языков.

Например, согласно CIRA , .caдоменные имена Канады разрешены:

• Письма aчерез zи следующие акцентированные символы: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Обратите внимание, что доменные имена не чувствительны к регистру. Это означает, что не будет проводиться различий между заглавными и строчными буквами ( A= a);

• Числа 0123456789и

• Символ дефиса (" -) (хотя его нельзя использовать для начала или окончания доменного имени).

Максимальная длина составляет 63 символа, за исключением того, что каждый акцентированный символ уменьшает этот предел на 4 символа.

( Источник )

_{Кстати, это позволяет использовать около 4 возможностей доменных имен Quadragintillion (не считая поддоменов) для доменов dot-ca.}

Вот мои 2 цента из мира Java:

Из консоли 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

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

Только что создал локальный проект (с vagrant), и он работал отлично при доступе по IP-адресу. Затем я добавил some_name.test в файл hosts и попытался получить к нему доступ таким образом, но все время получал «неверный запрос - 400». Потраченные впустую часы, пока я не понял, что просто смена доменного имени на some-name.test решает проблему. Так что по крайней мере локально в Mac OS это не работает.

Нет, вы не можете использовать подчеркивание в поддомене, но вы можете использовать Hypen (тире). т.е. my-subdomain.agahost.com является приемлемым, а my_subdomain.agahost.com не будет приемлемым.

Нет, если вы хотите, чтобы это разрешить в Интернете.

Вы не можете иметь: http://my_subdomain.example.com является недействительным.

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