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

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

7 ответов


большинство ответов здесь 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 "хозяина Имена и цифры", который ограничивает хостов в буквы-цифры-дефис.


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

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

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

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

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

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

так подчеркивает в хоста нет-нет, подчеркивает в доменные имена are a-ok.

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

заметка о кодировке

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

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

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

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

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

RFC 5890 вводит термин LDH (буква-цифра-Гипен) этикетка на метки в хоста и говорит:

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

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

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

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


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

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


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

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

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

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

С RFC5890

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

Punycode кодирует все кодовые точки ASCII как ASCII напрямую, включая подчеркивание. Полученный R-LDH не будет соответствовать правилам метки LDH. Например, Σ_.com будет закодировано как xn--_-zmb.com что нарушает правила. Может быть гомографическая кодовая точка, которая выглядит как подчеркивание, которое может быть закодировано юридически (возможно, ' _ ' U+ff3f fullwidth low line), но эти виды кодовых точек будут классифицированы как запрещенные 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 с дефисом.