RFC-952 (последнее предложение пункта 1 в разделе «Предположения») запрещает использование односимвольных имен хостов, и у меня был опыт (более 7 лет назад лето 2002 г.), где некоторые службы отказывались работать с односимвольными именами хостов (потому что такие имена не соответствовали стандартам), но я видел несколько односимвольных имен хостов, используемых в последние несколько лет. Допустимы ли теперь односимвольные имена хостов? (Если да, то какова правильная ссылка на валидацию?)
редактировать (чтобы обобщить некоторую информацию из ответов): различные аспекты DNS, похоже, определены в нескольких RFC, в том числе 1035, 1123, и 2181. Из RFC-2181, раздел 11:
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.
The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets. Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names. In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
И, наконец, как упоминалось ранее, из RFC-952:
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.
Следуя этой цепочке, я изначально пришел к выводу, что RFC-952 запрещает использование односимвольных имен хостов.
Можно подумать, что они действительны, потому что все корневые серверы имен являются однобуквенными хостами (a.root-servers.net), и спецификация DNS не создает для них специального исключения. Рассматриваемый RFC предназначен специально для формата хост-файла, а не для DNS. DNS был определен в более позднем RFC (RFC 1035 запускает это). RFC 1123 (1989) ясно заявляет об этом.
The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.
Таким образом, однобуквенные имена хостов действительны в системах на основе DNS и используются еще до изобретения спама. Системы, не соответствующие RFC, могут подвергаться издевательствам. Если они вообще не используют DNS, а используют только файлы хостов, тогда жалость - лучший выбор.
Поскольку имена хостов появились раньше, чем кто-либо даже подумал о написании о них RFC, я не вижу причин, по которым односимвольные имена хостов должны внезапно стать «незаконными». Этот конкретный RFC потерял меня, когда заявил
Этот RFC является официальной спецификацией
потому что RFC НЕ является стандартом. Даже не близко.
Несмотря на вышесказанное, необходимо отметить, что рассматриваемый RFC был создан для обращения к относительно небольшой группе, а именно к Министерству обороны (предположительно США).
Есть разница между «действительно» и «это работает». Вполне возможно, что имена хостов недействительны, если они состоят из одиночных символов (не выдерживая моей предыдущей публикации). Однако довольно много систем позволяют это сделать. Одна из основных систем, система Microsoft AD / DNS, имеет устаревшую причину для разрешения односимвольных имен.
Старые имена NetBIOS могут иметь длину от 1 до 15 символов. Эта спецификация была разработана независимо от RFC952, она основана на другом файле под названием lmhosts, поэтому она работает. Проблема возникла, когда Microsoft перешла с NetBEUI (на самом деле NBF, NetBIOS Frame Protocol) на TCP / IP (фактически NBT), и Microsoft пришлось разрешить разрешение имен в сетях TCP / IP. MS решила поддерживать разрешение в стиле NetBIOS с серверами WINS, избегая необходимости в хостах, соответствующих RFC952.
Затем появился Active Directory и его зависимости от DNS. Динамический DNS был правилом, поэтому клиенты должны были зарегистрировать свое имя компьютера (первые 15 символов которого также являются их именем NetBIOS) в домене DNS. Поскольку MS позволяет регистрировать односимвольные имена NetBIOS в DNS, это привело к конфликту с RFC952. Они решили кодировать свои системы, чтобы разрешить это, поскольку это имитировало то, как это всегда работало во времена WINS.
BIND DNS также допускает использование односимвольных имен хостов. Но RFC2181 в значительной степени прямо заявляет, что приложениям больше нужно проверять свои собственные данные, а не DNS. В результате у нас остается большое количество устройств и программного обеспечения, для которых односимвольные имена хостов вполне подходят, и несколько отклоняющихся от стандарта RFC952, которые не допускают этого.
Я думаю, что текущие имена хостов больше зависят от спецификаций DNS, поскольку DNS - это то, что большинство людей будет использовать в сети или в Интернете. Сказал, что на ум приходят три RFC (1034 - концепции, 1035 - реализация и 2181 - пояснения по поводу DNS).
Раздел 3 RFC 1034 говорит:
Пространство доменных имен представляет собой древовидную структуру. Каждый узел и лист на дереве соответствует набору ресурсов (который может быть пустым). Система доменов не делает различий между использованием внутренних узлов и листьев, и в этом документе термин «узел» используется для обозначения обоих.
Каждый узел имеет метку длиной от нуля до 63 октетов. Узлы Brother могут иметь разные метки, хотя одна и та же метка может использоваться для узлов, не являющихся братьями. Одна метка зарезервирована, и это пустая метка (т. Е. Нулевой длины), используемая для корня.
И в Раздел 11 RFC 2181 у нас есть пояснение по поводу наименования каждого узла адреса:
Сам DNS накладывает только одно ограничение на отдельные метки
которые можно использовать для идентификации записей ресурсов. Это одно ограничение
относится к длине этикетки и полному имени. Длина любой метки ограничена от 1 до 63 октетов. Полное доменное имя ограничено 255 октетами (включая разделители).
Итак, в свете спецификаций DNS у вас может быть a.domain.tld
Как вы определили, RFC 1123 не совсем ясен по этому вопросу.
В разделе 2.1 говорится:
Программное обеспечение хоста ДОЛЖНО обрабатывать имена хостов длиной до 63 символов и ДОЛЖНО обрабатывать имена хостов длиной до 255 символов.
Поскольку этот текст фактически полностью переопределяет текст из RFC 952, следует также понимать, что любой длина до 255 символов допустима.
К сожалению, еще в 1989 году Internet Drafts не получили той невероятно строгой проверки, которую получают сейчас, так что двусмысленность, вероятно, просто не была замечена.