Номер в домене верхнего уровня?
Может ли домен верхнего уровня содержать число в конце? Ничего не знаю о правилах DNS и т. Д., Но когда я пытаюсь использовать функцию PHP filter_var() с FILTER_VALIDATE_EMAIL для test@null.com1 это возвращает истину.
2 ответа
Концептуально, ничто не запрещает номера в ДВУ, и в будущем, кто знает, возможно, будут числовые ДВУ.
В настоящее время нет TLD, в которых есть номера - функция, вероятно, не проверяет список известных TLD (поскольку он может быть изменен), но лексически.
Может ли домен верхнего уровня содержать число в конце?
Да, технически, за исключением случаев, когда он носит чисто цифровой характер, он не может быть ДВУ в соответствии с действующими правилами и по понятным причинам (для устранения неоднозначности с использованием IP-адресов). И он не может содержать номер в конце, за исключением случаев, когда речь идет о IDN TLD, по причинам, навязанным ICANN.
Давайте вернемся к некоторым RFC, чтобы получить более четкие определения вещей:
RFC 952: DOD ИНТЕРНЕТ ХОЗЯЙСТВЕННАЯ ТАБЛИЦА СПЕЦИФИКАЦИЯ (октябрь 1985 г.)
Это определение интернет-имени хоста тогда:
"Имя" (Net, Host, Gateway или Domain name) представляет собой текстовую строку вверх
до 24 символов, взятых из алфавита (AZ), цифры (0-9), минус
знак (-) и точка (.). Обратите внимание, что периоды разрешены только тогда, когда
они служат для разграничения компонентов "имен стилей домена". (Увидеть
RFC-921, "График внедрения системы доменных имен", для
фон). Никакие пробелы или пробелы не допускаются как часть имени. Не делается различий между прописными и строчными буквами. Первый символ должен быть символом альфа. Последний символ не должен быть знаком минус или точкой.
Обратите внимание, что имеет также:
Односимвольные имена или псевдонимы не допускаются.
Следовательно, в этот момент:
com1является действительным TLD3comне ("Первый символ должен быть буквенным символом.")42нет (по той же причине)1нет (по той же причине)aне является ("Однозначные имена или псевдонимы не допускаются.")
RFC 1034: ДОМЕННЫЕ ИМЕНА - КОНЦЕПЦИИ И ОБЪЕКТЫ (ноябрь 1987 г.)
Это один из RFC, который создал DNS, как мы знаем сегодня. По причинам совместимости он определил имена хостов как последовательность меток, где метка определена так:
Они должны начинаться с буквы, заканчиваться буквой или цифрой и содержать в качестве внутренних символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Метки должны быть не более 63 символов.
TLD является одним из ярлыков среди других. Согласно приведенному выше правилу, com1 является действительной меткой, и, следовательно, TLD, где 3com не было бы. Что напрямую подводит нас к следующей поправке.
RFC 1123: требования к интернет-хостам - применение и поддержка (октябрь 1989 г.)
Это исправляет предыдущий RFC, изменяя одно правило:
Синтаксис допустимого имени хоста в Интернете был указан в RFC-952 [DNS:4]. Настоящим изменяется один аспект синтаксиса имени хоста: ограничение на первый символ смягчается, чтобы разрешить использование буквы или цифры. Программное обеспечение хоста ДОЛЖНО поддерживать этот более либеральный синтаксис.
Итак, на данный момент:
com1является действительным TLD3comтакже действует42является действительным1является действительнымaявляется действительным
В случае "числовых" TLD применяется следующее правило в первом документе:
Всякий раз, когда пользователь вводит идентификатор хоста в Интернете, СЛЕДУЕТ вводить (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 по умолчанию вообще не учитывает чисто числовые ДВУ, но для этого предусмотрена заплатка: 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 и доменными именами хоста. В любом случае разумно полагать, что ограничения были приняты в некоторых развернутых программах и что изменения в правилах следует предпринимать с осторожностью.
Следовательно, он предложил это определение:
традиционный 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, начинающегося с цифры или чисто числового значения (это работало, если это закончилось цифрой с буквами раньше). Это не считалось ошибкой и не исправлено, потому что браузер поставляется со списком 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 должна состоять исключительно из букв (букв алфавита az) или
Метка должна быть действительной меткой А IDNA (далее ограничена, как описано в части II ниже).
Особо обратите внимание: метка ASCII должна состоять исключительно из букв (букв алфавита az)
Это немедленно запрещает вводить любые полные числовые, а также фактически любые цифры, в том числе в конце, за исключением 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-адреса.
Тот факт, что TLD является буквенным, часто является ключевым фактором, определяющим программное обеспечение при идентификации доменного имени. Если бы разрешен домен верхнего уровня, например ".123", у вас могло бы быть доменное имя "74.125.244.123", которое было бы трудно отличить от IP-адреса "74.125.244.123". Есть и другие соображения: в документации по техническим стандартам указано, что ДВУ будут алфавитными, что также было кодифицировано как допущение в программном обеспечении.
Ограничение в AGB буквенными символами было разработано, чтобы ограничить эти сценарии, что означает, что такие TLD вряд ли будут хорошо работать в программном обеспечении, а также ограничит потенциальные проблемы безопасности, которые могут возникнуть из-за тех же проблем.
На самом деле в настоящее время используется довольно много TLD, которые содержат номера:
XN--1QQW23A XN--3BST00M XN--3DS443G XN--3E0B707E XN--45BRJ9C XN--4GBRIM XN--55QW42G XN--55QX5D XN--6FRZ82G XN--6QQ986B3XL XN--80ADXHKS XN--80AO21A XN--80ASEHDB XN--80ASWG XN--90A3AC XN--C1AVG XN--CG4BKI XN--CLCHC0EA0B2G2A9GCD XN--CZR694B XN--CZRU2D XN--D1ACJ3B XN--FIQ228C5HS XN--FIQ64B XN--FIQS8S XN--FIQZ9S XN--FPCRJ9C3D XN--FZC2C9E2C XN--GECRJ9C XN--H2BRJ9C XN--I1B6B1A6A2E XN--IO0A7I XN--J1AMH XN--J6W193G XN--KPRW13D XN--KPRY57D XN--KPUT3I XN--L1ACC XN--LGBBAT1AD8J XN--MGB9AWBF XN--MGBA3A4F16A XN--MGBAAM7A8H XN--MGBAB2BD XN--MGBAYH7GPA XN--MGBBH1A71E XN--MGBC0A9AZCG XN--MGBERP4A5D4AR XN--MGBX4CD0AB XN--NGBC5AZD XN--NQV7F XN--NQV7FS00EMA XN--O3CW4H XN--OGBPF8FL XN--P1AI XN--PGBS0DH XN--Q9JYB4C XN--RHQV96G XN--S9BRJ9C XN--SES554G XN--UNUP4Y XN--VHQUV XN--WGBH1C XN--WGBL6A XN--XHQ521B XN--XKC2AL3HYE2A XN--XKC2DL3A5EE0H XN--YFRO4I67O XN--YGBI2AMMX XN--ZFR164B
Вы можете увидеть актуальный список здесь http://data.iana.org/TLD/tlds-alpha-by-domain.txt или список с описанием здесь http://swcs.com.au/tld.htm