Допустимы ли однобуквенные имена хостов?

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.

Из RFC-1123, раздел 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].

Из RFC-1123 раздел 2.1 :

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 запрещает имена хостов из одного символа.

Существует разница между «действительным» и «оно работает». Вполне возможно, что имена хостов не считаются действительными, если они состоят из одного символа (мой предыдущий пост не выдержал). Тем не менее, довольно много систем позволяют им. Одна из основных систем, система 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 разрешает регистрировать в DNS односимвольные имена NetBIOS, это привело к конфликту с RFC952. Они решили кодировать свои системы, чтобы разрешить это, так как это имитировало то, как это всегда работало в дни WINS.

BIND DNS также допускает использование односимвольных имен хостов. Но RFC2181 в значительной степени утверждает, что приложения должны проверять свои собственные данные, а не DNS. Это оставляет нас с большим количеством устройств и программного обеспечения, для которых хорошо подходят одно-символьные имена хостов, и несколько выбросов, которые строго соответствуют RFC952 и не позволяют этого.

Вы могли бы подумать, что они действительны, потому что все корневые серверы имен - это однобуквенные хосты (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 был создан для того, чтобы относиться к относительно небольшой группе, а именно к Министерству обороны (предположительно, из США).

Я думаю, что текущие имена хостов в большей степени зависят от спецификаций DNS, поскольку DNS - это то, что большинство людей будет использовать в сети или в Интернете. Сказал, что на ум приходят три RFC (1034 - концепции, 1035 - реализация и 2181 - разъяснения по DNS).

Раздел 3 RFC 1034 гласит:

Пространство доменных имен представляет собой древовидную структуру. Каждый узел и лист дерева соответствуют набору ресурсов (который может быть пустым). Система доменов не делает различий между использованием внутренних узлов и листьев, и в этом примечании термин «узел» используется для обозначения обоих.

Каждый узел имеет метку длиной от 0 до 63 октетов. Узлы-братья могут не иметь одинаковую метку, хотя одна и та же метка может использоваться для узлов, которые не являются братьями. Одна метка зарезервирована, и это нулевая (то есть нулевая длина) метка, используемая для корня.

И в Разделе 11 RFC 2181 у нас есть разъяснение о присвоении имен каждому узлу адреса:

Сам DNS накладывает только одно ограничение на конкретные метки,
которые можно использовать для идентификации записей ресурсов. Это одно ограничение
касается длины метки и полного имени. Длина любой метки ограничена от 1 до 63 октетов. Полное доменное имя ограничено 255 октетами (включая разделители)

Таким образом, в свете спецификаций DNS, вы можете иметь a.domain.tld

Как вы уже определили, RFC 1123 не совсем ясно по этому вопросу длины.

Раздел 2.1 действительно говорит:

Программное обеспечение хоста ДОЛЖНО обрабатывать имена хостов длиной до 63 символов и ДОЛЖНО обрабатывать имена хостов длиной до 255 символов

Поскольку этот текст фактически полностью переопределяет текст из RFC 952, следует также понимать, что любая длина до 255 символов является допустимой.

К сожалению, еще в 1989 году интернет-шашки не получили невероятно сурового обзора, который они получают сейчас, поэтому двусмысленность, вероятно, просто не заметили.