Чи можуть піддомени (доменне ім’я) мати в ньому підкреслення "_"?

Чи можуть субдомени (доменні імена) мати _в них підкреслення ?

Більшість наведених тут відповідей є хибними . Цілком законно мати підкреслення у доменному імені. Дозвольте мені процитувати стандарт, 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
• Мітка - це частина доменного імені між крапками
• ім'я хоста - це особливий тип доменного імені, який ідентифікує Інтернет-хостів

Ім'я хоста підпадає під обмеження 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" зазначає:

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

Можливо, вам потрібно знати: Якщо хост або піддоменна частина URL містить підкреслення, IE9 (не перевіряли інші версії) не може писати файли cookie.

Тож будьте обережні з цього приводу. :-)

Уточнюючі бортсмейєри та Девід Тонхофер , мітки доменних імен та субдоменних імен можуть містити провідні підкреслення, але більше ніде.

Як писав Девід Тонхофер , мітки - це частини між періодами, які повинні дотримуватися правила 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 і не повинна використовуватися.

Я перейшов за посиланням на RFC1034 і прочитав більшість із них, і здивувався, побачивши це:

Мітки повинні відповідати правилам для імен хостів ARPANET. Вони повинні починатися з літери, закінчуватися буквою або цифрою, а як внутрішні символи мають лише літери, цифри та дефіс. Існують також деякі обмеження щодо довжини. Мітки повинні містити 63 символи або менше.

Для уточнення доменні імена складаються з міток, які розділені крапками ".". Ця специфікація повинна бути застарілою, оскільки в ній не зазначається використання підкреслення. Я можу зрозуміти плутанину, якщо хтось наткнеться на цю специфікацію, не знаючи, що вона застаріла. Це застаріло, чи не так?

Я перейшов за посиланням на RFC2181 і прочитав його. Особливо, коли це стосується питання про те, що є авторитетним, або канонічним, ім'ям, а також те, що робить дійсною міткою DNS.

Як було розміщено раніше, в ній зазначено, що обмеження довжини є лише обмеженим, а потім підсумовувати таке:

(про імена та дійсні мітки)

Вони вже достатньо визначені, однак технічні характеристики, здається, часом ігноруються. Ми прагнемо посилити існуючі специфікації.

Вид мене залишає цікавим, чи "обмеження лише по довжині" є "адекватним". Ми почнемо бачити доменні імена, як @ # $% !! скоро? Хіба Інтернет недостатньо накручений?

Нещодавно форум CAB (*) вирішив це

Усі сертифікати, що містять символ підкреслення у будь-якому записі dNSName і мають термін дії більше 30 днів, ОБОВ'ЯЗКОВО бути відкликані до 15 січня 2019 року. Https://cabforum.org/2018/11/12/ballot-sc-12- захід сонця-підкреслення-в-dnsnames /

Це означає, що вам більше не дозволяється використовувати підкреслення в доменах, які матимуть сертифікат ssl / tls.

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

Індивідуальні TLD можуть розміщувати власні правила та обмеження щодо імен доменів, як вони вважають за потрібне, наприклад, для розміщення місцевих мов.

Наприклад, згідно з CIRA , .caдоменні імена Канади дозволяються:

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

• Числа 0123456789, і

• Дефіс (" -) (хоча його не можна використовувати для запуску або закінчення доменного імені).

Максимальна довжина - 63 символи, за винятком того, що кожен символ наголосу зменшує цю межу на 4 символи.

( Джерело )

_{Між іншим, це дозволяє приблизно 4 можливості доменних імен Quadragintillion (без урахування піддоменів) для точок-ca доменів.}

Ось мої 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

Це, безумовно, погана ідея ^^

Щойно створений локальний проект (з бродячим), і він прекрасно працював при доступі до ip-адреси. Потім я додав some_name.test до файлу хостів і намагався отримати доступ до нього таким чином, але весь час отримував "поганий запит - 400". Втрачені години, поки я не зрозумів, що просто зміна доменного імені на some-name.test вирішує проблему. Так принаймні локально на Mac OS це не працює.

Ні, ви не можете використовувати підкреслення в субдомені, але hypen (тире). тобто my-subdomain.agahost.com є прийнятним, а my_subdomain.agahost.com було б неприйнятним.

Не, якщо ви хочете, щоб це вирішили в Інтернеті.

Ви не можете мати: http://my_subdomain.example.com недійсний.

Ви можете мати http://my-subdomain.example.com із дефісом.