Может ли домен верхнего уровня содержать число в конце?
Да, технически, кроме случаев, когда он чисто числовой, он не может быть ДВУ, согласно действующим правилам ипо понятным причинам (для устранения неоднозначности с IP-адресами).И он не может содержать номер в конце, за исключением случаев, когда речь идет о TLD IDN, по причинам, навязанным ICANN.
Давайте вернемся к некоторым RFC, чтобы получить более четкие определения вещей:
RFC 952: спецификация таблицы хостов DOD INTERNET (октябрь 1985 г.)
Тогда это определение «имени хоста» в Интернете:
«имя» (Net, Host, Gateway или Domain name) - это текстовая строка длиной до
до 24 символов, взятая из алфавита (AZ), цифр (0-9), знака минус
(-) и точки (.).Обратите внимание, что периоды разрешены только в том случае, если
они служат для разделения компонентов «имен стилей домена».(См.
RFC-921, «График внедрения системы доменных имен», для
справочная информация).Никакие пробелы или пробелы не допускаются как часть имени.Не делается различий между прописными и строчными буквами.Первый символ должен быть символом альфа.Последний символ не должен быть знаком минус или точкой.
Примечание, которое также имеет:
Односимвольные имена или псевдонимы не допускаются.
Следовательно, в этот момент:
com1 является допустимым TLD 3com нет («Первый символ должен быть буквенным символом.») 42 нет (по той же причине) 1 нет (по той же причине) a нет («Односимвольные имена или псевдонимы недопустимы». ")
RFC 1034: ДОМЕННЫЕ ИМЕНА - КОНЦЕПЦИИ И ОБЪЕКТЫ (ноябрь 1987 г.)
Это один из RFC, который создал DNS, как мы знаем сегодня.По соображениям совместимости он определил имена хостов как последовательность меток, где метка определяется следующим образом:
Они должны начинаться с буквы, заканчиваться буквой или цифрой и иметь в качестве внутренних символов только буквы, цифры и дефис.Есть также некоторые ограничения по длине.Ярлыки должны содержать не более 63 символов.
TLD является одним ярлыком среди других.Согласно приведенному выше правилу, com1 является допустимой меткой, и, следовательно, TLD, где 3com не было бы.Что напрямую приводит нас к следующей поправке.
RFC 1123: Требования к хостам в Интернете - применение и поддержка (октябрь 1989 г.)
Это исправляет предыдущий RFC, изменяя одно правило:
Синтаксис допустимого имени хоста в Интернете был указан в RFC-952 [DNS: 4].Настоящим изменяется один аспект синтаксиса имени хоста: ограничение на первый символ смягчается, чтобы разрешить использование буквы или цифры.Программное обеспечение хоста ДОЛЖНО поддерживать этот более либеральный синтаксис.
Таким образом, в этот момент:
com1 является допустимым TLD 3com такжедействительный 42 действительный 1 действительный a действительный
Для случая "числовой"ДВУ, в первом документе применяется следующее правило:
Когда пользователь вводит идентификационные данные хоста в Интернете, СЛЕДУЕТ ввести либо (1) имя домена хоста, либо (2) IP-адресадрес в точечно-десятичной ("#. #. #. #") форме.Хост ДОЛЖЕН проверять строку синтаксически на наличие десятичного числа с точками, прежде чем искать ее в системе доменных имен.
и
Если десятичное число с точками может бытьвведенные без таких идентифицирующих разделителей, необходимо выполнить полную синтаксическую проверку, поскольку сегмент имени домена хоста теперь может начинаться с цифры и может юридически быть полностью числовым (см. раздел 6.1.2.4).Однако действительное имя хоста никогда не может иметь точечно-десятичную форму #. #. #. #, Так как по крайней мереметка компонента самого высокого уровня будет буквенной.
RFC 1738: унифицированные указатели ресурсов (URL) (декабрь 1994 г.)
Это также говорит о TLD, но дает
Полное доменное имя сетевого хоста или его IP
адрес как набор из четырех десятичных цифр групп, разделенных
"". Полностью определенные доменные имена принимают форму, как описано
в разделе 3.5 RFC 1034 [13] и в разделе 2.1 RFC 1123
[5]: последовательность доменных меток, разделенных символом «.», Каждый домен
метка начинается и заканчивается буквенно-цифровым символом и
возможно также содержит символы "-". Самый правый домен
метка никогда не будет начинаться с цифры, которая
синтаксически отличает все доменные имена от IP
адреса.
RFC 3696: методы применения для проверки и преобразования имен (февраль 2004 г.)
Это было необходимо для введения IDN (интернационализированных доменных имен), и он имеет следующее:
Любые символы или комбинация битов (как октеты) разрешены в
DNS-имена. Тем не менее, есть предпочтительная форма, которая требуется
большинство приложений. Эта предпочтительная форма была единственной
разрешено в именах доменов верхнего уровня или TLD. В общем, это
это также единственная форма, разрешенная для большинства зарегистрированных имен второго уровня
в TLD, хотя некоторые имена, которые обычно не видны пользователям, подчиняются
другие правила. Это вытекает из оригинальных правил ARPANET для
наименование хостов (то есть правило "имя хоста") и, возможно, лучше
описывается как «правило LDH», после символов, которые оно разрешает.
Обновленное правило LDH предусматривает, что метки (слова или строки
разделенные точками), которые составляют доменное имя, должно состоять только из
буквенные и числовые символы ASCII [ASCII], а также дефис.
Другие символы или знаки препинания не допускаются, равно как
пустое пространство. Если используется дефис, он не может появляться на
либо начало, либо конец метки. Есть дополнительное правило
что по сути требует, чтобы доменные имена верхнего уровня не были полностью
Числовой.
Фактически, как только IDN задействованы, и они являются IDN TLD (теперь и ccTLD, и gTLD), выбранная кодировка генерирует строку ASCII в форме xn--something, где что-то может иметь цифры, в том числе в конце, как показано в других ответах.
Однако не совсем ясно, откуда взято «дополнительное правило» в последнем предложении.
RFC 4697: наблюдаемое неправильное поведение при разрешении DNS (октябрь 2006 г.)
Ничего не определяя, но приводя некоторые интересные факты:
Корневые серверы имен получают значительное количество записей A
запросы, где QNAME выглядит как адрес IPv4.
и
Возможное решение - делегировать эти числовые TLD.
из корневой зоны на отдельный набор серверов для поглощения
трафика.
Что ясно показывает, что на самом деле в дикой природе существуют приложения, возможно, по ошибке, но, по крайней мере, это показывает, что они работают технически, отправляя запросы на имена, которые действительно отформатированы как адреса IPv4, то есть с полностью числовым «TLD» .
На самом деле был опыт запуска реестра .42, очевидно, полностью за пределами экосистемы ICANN. Вы можете увидеть его краткое изложение в http://www.dotsauce.com/experimental-numeric-tld-42-domain/ и архив с их основными объяснениями в https://web.archive.org/web/20101222151118/http://register.42registry.org:80/ (на французском языке).
Это не зашло далеко, даже если это технически работает.
Это показало, например, что операционная система на базе Microsoft по умолчанию вообще не учитывает чисто числовые TLD, но они предоставили исправление для этого: https://support.microsoft.com/en-us/help/947228/error-message-when-you-try-to-join-a-windows-vista-based-client-comput "При попытке присоединиться к клиентскому компьютеру на базе Windows Vista для домен верхнего уровня (TLD) с чисто числовым суффиксом, клиентский компьютер под управлением Windows Vista не может присоединиться к домену. [..] Такое поведение предусмотрено. "
Internet-Draft draft-liman-tld-names-06: Спецификация доменного имени верхнего уровня (ноябрь 2011 г.)
В заключение приводятся некоторые объяснения того, почему чисто числовые ДВУ или даже ДВУ с одной цифрой иногда считаются недействительными, если это не является явным следствием указанных выше спецификаций:
(раздел 2.1 ниже относится к содержанию в RFC 1123, указанном выше)
Кроме того, в разделе ОБСУЖДЕНИЕ в разделе 2.1 говорится:
'However, a valid host name can never have the dotted-decimal form
#.#.#.#, since at least the highest-level component label will be
alphabetic.' [Section 2.1]
Некоторые разработчики, возможно, поняли приведенную выше фразу «будет
алфавитный », чтобы быть ограничением протокола.
Но в основном просто рекомендую пойти по течению и продолжить те же ограничения:
Ни в [RFC0952], ни [RFC1123] явно не указаны причины
эти ограничения. Можно предположить, что человеческий фактор был
рассмотрение; [RFC1123], кажется, предполагает, что одна из причин
должен был предотвратить путаницу между точечно-десятичными адресами IPv4 и
доменные имена хоста. В любом случае разумно полагать, что
ограничения были приняты в некоторых развернутого программного обеспечения, и что
Изменения в правилах следует предпринимать с осторожностью.
Следовательно, он предложил это определение:
Traditional-tld-label = 1 * 63 (ALPHA)
Этот черновик никогда не преобразовывался в RFC, потому что не все с ним согласились. Вы можете найти тему с несогласными голосами для этого в https://www.ietf.org/mail-archive/web/dnsop/current/msg08866.html; в основном было неясно, было ли в прошлом ограничение, что мы сейчас пытаемся немного расслабиться, или не было ограничения с самого начала, и что люди неправильно внедрили системы.
Например, вы можете увидеть об этом отчете об ошибках Chromium / Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=31405
Сбой просмотра при использовании ДВУ, начинающегося с цифры или чисто числового (он работал, если раньше он заканчивался цифрой с буквами). Это не считалось ошибкой и не исправлено, поскольку браузер поставляется со списком TLD, поэтому он может знать, какие из них действительны, а какие нет, кроме проверки их синтаксиса.
Руководство ICANN по заявкам на новые ДВУ (июнь 2012 г.)
Доступно в https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf
на странице 64 написано следующее:
Метка ASCII (т. Е. Метка, передаваемая по проводам) должна быть действительной, как указано в технических стандартах «Имена доменов: реализация и спецификация» (RFC 1035) и пояснения к спецификации DNS (RFC 2181) и любым ее обновлениям. ,
Метка ASCII должна быть действительным именем хоста, как указано в Технических стандартах Спецификация таблицы хостов Интернета DOD (RFC 952), Требования к хостам Интернета - Приложение и поддержка (RFC 1123), а также Методы применения для проверки и преобразования Имена (RFC 3696), интернационализированные доменные имена в приложениях (IDNA) (RFC 5890-5894) и любые их обновления. Это включает в себя следующее:
Метка ASCII должна состоять исключительно из букв (буквенных символов a-z) или
Метка должна быть действительной IDNA-меткой A (далее ограничена, как описано в Части II ниже).
Особо обратите внимание на: Метка ASCII должна состоять полностью из букв (буквенных символов a-z)
Это немедленно запрещает вводить любые полные цифры, а также фактически любые цифры, в том числе в конце, за исключением IDN TLD, которые имеют форму xn--something.
Обратите внимание, что кто-то напрямую спросил об этом ICANN и получил следующий ответ, показанный в https://domaingang.com/domain-news/icann-applicant-handbook-this-is-why-we-cannot-have-numeric-gtlds/:
Обратите внимание, что числовые ДВУ были запрещены в первом раунде подачи заявок.Запрет на числовые рДВУ в руководстве кандидата (http://newgtlds.icann.org/en/applicants/agb) обусловлен рядом технических проблем, касающихся способности таких доменов функционировать должным образом. Доменные имена часто используются там, где могут использоваться другие виды идентификаторов, такие как IPадреса.
Тот факт, что ДВУ полностью алфавитный, часто является ключевым фактором, определяющим программное обеспечение при идентификации доменного имени. Если бы ДВУ, например «.123», было разрешено, вы могли бы иметь доменное имя «74.125»..244.123 », который было бы трудно отличить от IP-адреса« 74.125.244.123. ». Есть и другие соображения: в документации по некоторым техническим стандартам указано, что ДВУ будут алфавитными, что было также кодифицировано как допущение в программном обеспечении.*
Ограничение в AGB буквенными символами было разработано, чтобы ограничить эти сценарии, что означает, что такие TLD вряд ли будут хорошо работать в программном обеспечении, а также ограничит потенциальные проблемы безопасности, которые могут возникнуть из-за тех же проблем.