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

Question

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

Answer 1

Большинство ответов, приведенных здесь: false . Совершенно законно иметь подчеркивание в доменном имени. Позвольте мне процитировать стандарт, 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 "Хост Имена и номера », ограничивающие имена хостов буквы-цифры-дефис.

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

С RFC5890

[..] два новых подмножества меток LDH создаются введение IDNA. Они называются зарезервированными метками LDH (R-LDH метки) и незарезервированные метки LDH (метки NR-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 в качестве стандарта и не должна использоваться.

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

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

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

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

Answer 7

Вот мои 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

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

Answer 8

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

Например, согласно CIRA , .ca доменных имен Канады допускаются:

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

• Числа 0123456789 и

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

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

( Источник )

---

_{Между прочим, это позволяет около 4 Quadragintillion возможностей доменных имен (не считая поддоменов) для доменов точка-CA.}

Answer 9

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

Вы не можете иметь: http://my_subdomain.example.com неверно.

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