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


212

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


12
Я буквально ответил на ваш вопрос: что вы действительно имели в виду DOMAIN NAMES. Если вместо этого вы имели в виду HOST NAMES, отредактируйте свой вопрос, потому что ответ будет другим.
bortzmeyer

Ответы:


362

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


73
+1 за разницу между «доменными именами» и «именами хостов»
Альнитак

3
Вопрос (если он не был отредактирован) о поддоменах, т.е. имена хостов. Вы не ошиблись в своих фактических утверждениях, за исключением того, что указали, что ответы являются ложными, исходя из того, как вопрос сформулирован в настоящее время.
Redreinard

4
Я в замешательстве, 1034 говорит: «Метки должны соответствовать правилам для имен хостов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и содержать в качестве внутренних символов только буквы, цифры и дефис». Какая часть этого позволяет подчеркнуть?
Claudekennilol

2
Формулировка сбивает с толку. URL не могут иметь подчеркивания. URL-адрес всегда является полным доменным именем, а не именем хоста. Полное доменное имя может иметь пустое имя хоста, в этом случае полное доменное имя = домен. _jabber._tcp.gmail.comэто не домен, это полное доменное имя. Поскольку URL-адреса не могут быть подчеркнуты, вы, вероятно, никогда не сможете купить домен с подчеркиванием в нем. Таким образом, даже у доменов могут быть подчеркивания с точки зрения синтаксиса DNS, вы никогда не встретите их, если только они не являются локальными.
Капсула

1
Я не вижу цитаты в 2.1 из rfc1123, в которой упоминается что-либо о разрешенных дефисах. В rfc952 я вижу, что имя может быть <let-or-digit-or-hyphen>. Это то, что вы имели в виду?
AJP

93

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

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

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


С другой стороны: «Такие системы, как DomainKeys и служебные записи, используют подчеркивание как средство, чтобы гарантировать, что их специальный символ не будет перепутан с именами хостов. Например, _http._sctp.www.example.com указывает сервисный указатель для SCTP способный хост веб-сервера (www) в домене example.com. " ( ссылка )
х-юрий

Не обращая внимания на части кодирования RACE, IDN уже установил преобразование интернаитонизированных символов в ASCII с использованием префикса 'xn--'.
mootmoot

2
@ Nelda.techspiress Это было некоторое время , но в соответствии с RFC 1034: доменные имена - понятий и объектов , что называется «субдомно» домен bar.baz.(к примеру) только совокупность доменных имен, которые иерархически под bar.baz., например a.bar.baz., f.g.bar.baz., h.bar.baz.и т. д. Этот «поддомен» может включать или не включать действительные имена хостов. .
Дэвид Тонхофер

2
При ежедневном использовании можно попытаться неправильно назвать строку a.bar.baz(имя домена) «поддоменом» строки bar.baz(другое имя домена). Доменные имена (ресурсы базы данных DNS)a.bar.baz и bar.bazмогут или не могут быть имена хостов .
Дэвид Тонхофер

1
На странице 8 RFC 1034 мы читаем: «Домен идентифицируется по имени домена и состоит из той части пространства имен домена, которая находится на или ниже имени домена, которое определяет домен. Домен - это поддомен другого домена, если он содержится в этом домене. Это отношение можно проверить, посмотрев, заканчивается ли имя субдомена именем содержащего домена. Например, ABCD является поддоменом BCD, CD, D и "".
Дэвид Тонхофер

47

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

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



3
У нас это было просто в проекте - и я собирался сходить с ума от странных проблем с IE. Пока мы не обнаружили подчеркивание в поддомене. ; о)
Кай Маттерн

3
Все еще проблема в IE10. MS знает об этом?
Петр Кула

15
Более актуально: заботится ли об этом MS?
Аякс


11

Разъясняющие 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 в качестве стандарта и не должна использоваться.


1
В заключение. Не могу поверить, что это единственный пост на всей странице, который даже говорит о Punycode.
Пейсер

6

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

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

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

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

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

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

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

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


3
Нет, это не устарело. RFC1034 - это спецификация имен хостов , особый случай доменных имен , которые являются общими идентификаторами ресурсов в базе данных DNS. Например, «host» часть URI определяется довольно спокойно ( tools.ietf.org/html/rfc3986#section-3.2.2 ), но RFC предупреждает: «Хост, идентифицируемый зарегистрированным именем, обычно представляет собой последовательность символов предназначен для поиска в локально определенном реестре хостов или имен служб ... зарегистрированное имя, предназначенное для поиска в DNS, использует синтаксис, определенный в Разделе 3.5 [RFC1034] и Разделе 2.1 [RFC1123]. "
Дэвид Тонхофер

3

Недавно 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) ниже).


1

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

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

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

  • Числа 0123456789и

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

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

( Источник )


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


0

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

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


0

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


0

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


-2

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

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

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


Это после 15 января 2019 года - ваш контрпример не работает.
Джо Inwap

@JoeInwap Можете ли вы указать мне источник вашего комментария?
Анкша

Я шел по cabforum.org/2018/11/12/… и тому факту, что o_o.lgms.nl представляет сертификат, который недействителен для этого имени хоста. Имя, однако, разрешает.
Джо Инвап
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.