Могут ли субдомены (доменное имя) иметь подчеркивание "_"?
Могут ли субдомены (доменные имена) иметь подчеркивание _ в них?
13 ответов
Большинство ответов, приведенных здесь, являются ложными. Совершенно законно иметь подчеркивание в доменном имени. Позвольте мне процитировать стандарт 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 веке оказывается, что имена хостов, а также доменные имена могут быть интернационализированы! Это означает использование кодировок в случае меток, которые содержат символы, которые находятся за пределами допустимого набора.
В частности, он позволяет кодировать _ в именах хостов (Обновление 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, полная ширина полосы), но эти типы кодовых точек будут классифицированы как ОТКЛЮЧЕНЫ RFC5892 согласно 2.3 IgnorableProperties как Noncharacter_Code_Point.
RACE (другая предложенная схема кодирования IDN) не была принята IETF в качестве стандарта и не должна использоваться.
Недавно 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(a)(1) и (2) ниже) и поставщиков программного обеспечения для интернет-браузера и других приложений, которые использовать сертификаты (потребители сертификатов, как определено в разделе 2.1 (а)(3) ниже).
По состоянию на 2023 год в поиске Google появляются веб-сайты, субдомены которых содержат символы подчеркивания, например https://my_sarisari_store.typepad.com .
Я перешел по ссылке на RFC1034 и прочитал большую ее часть, и был удивлен, увидев это:
Метки должны соответствовать правилам для имен хостов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и содержать в качестве внутренних символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Метки должны быть не более 63 символов.
Для пояснения доменные имена состоят из меток, разделенных точками "." Эта спецификация должна быть устаревшей, потому что она не упоминает использование подчеркивания. Я могу понять путаницу, если кто-то наткнется на эту спецификацию, не зная, что она устарела. Это устарело, не так ли?
Я перешел по ссылке на RFC2181 и прочитал некоторые из них. Особенно там, где это касается вопроса о том, что является авторитетным или каноническим именем, и вопроса о том, что делает действительной метку DNS.
Как сообщалось ранее, в нем говорится, что есть только ограничение по длине, а затем, чтобы подвести итог:
(об именах и допустимых ярлыках)
Они уже определены надлежащим образом, однако спецификации иногда игнорируются. Мы стремимся усилить существующие спецификации.
Отчасти меня удивляет, является ли "ограничение длины только" "адекватным". Мы собираемся начать видеть доменные имена, такие как @#$%!! скоро? Разве Интернет не испорчен достаточно?
Вот мои 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
Это определенно плохая идея ^^
Независимо от обсуждения имени хоста и имени домена, использование подчеркивания в части URL-адреса в хост-части - это определенно очень плохая идея. Это вызовет у вас горе. Он вполне может работать в браузере, но в одном случае я недавно столкнулся с приложением, которое отказывалось установить tls-соединение с совершенно действующим сертификатом с подстановочными знаками для *.s3. amazonaws.com, потому что часть имени хоста с подстановочными знаками содержит подчеркивание и не будет проверяться. Я считаю, что базовая библиотека использовала openssl.
Отдельные домены верхнего уровня могут устанавливать свои собственные правила и ограничения для доменных имен по своему усмотрению, например, для размещения местных языков.
Например, согласно CIRA, Канада.caдоменные имена разрешены:
Буквы
aчерезzи следующие акцентированные символы:é ë ê è â à æ ô œ ù û ü ç î ï ÿ, Обратите внимание, что доменные имена не чувствительны к регистру. Это означает, что не будет проводиться различий между заглавными и строчными буквами (Aзнак равноa);Число
0123456789, а такжеСимвол дефиса ("
-) (хотя егонельзя использовать для начала или окончания доменного имени).
Максимальная длина составляет 63 символа, за исключением того, что каждый акцентированный символ уменьшает этот предел на4 символа.
( Источник)
Кстати, это позволяет использовать около4 возможностей доменных имен Quadragintillion (не считая поддоменов) для доменов dot-ca.
Нет, вы не можете использовать подчеркивание в поддомене, кроме дефиса (тире). т.е. my-subdomain.agahost.com является приемлемым, а my_subdomain.agahost.com - неприемлемым.
Только что создал локальный проект (с бродягой), и он отлично работал при доступе по IP-адресу. Затем я добавил some_name.test в файл hosts и попытался получить к нему доступ таким образом, но все время получал "плохой запрос - 400". Потраченные впустую часы, пока я не понял, что простая замена доменного имени на some-name.test решает проблему. Так что, по крайней мере, локально в Mac OS он не работает.
Нет, если вы хотите, чтобы это разрешить в Интернете.
Вы не можете иметь: http://my_subdomain.example.com/ является недействительным.
Вы можете иметь: http://my-subdomain.example.com/ с дефисом.