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

Ответ 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" Host Names and Numbers ", который ограничивает имена хостов буквы-цифры дефис.

Ответ 2

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

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

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

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

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

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

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

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

Заметка о кодировании

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

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

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

• RFC 5890 "IDNA: Определения и рамки документов"
• RFC 5891 "IDNA: Protocol"
• RFC 5892 "Кодовые точки Юникода и 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 октетов.

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

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

Ответ 3

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

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

Ответ 4

Уточнение bortzmeyer и Дэвид Тонхофер, названия имен доменных имен и поддоменов могут содержать символы подчеркивания, но нигде иначе.

Как написал Дэвид Тонгофер, ярлыки являются частями промежуточного периода и должны следовать правилу 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 метки, известные как "помеченные имена доменов" в некоторых других контекстах, имеют свойство, которое они содержат "-" в третьем и четвертом символов , но которые в противном случае соответствуют правилам метки 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 и не должна использоваться.

Ответ 5

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

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

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

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

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

(имена и допустимые метки)

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

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

Ответ 6

Здесь мои 2 цента от мира Java:

Из консоли Spark Scala с Java 8:

Это окончательно плохая идея ^^