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

14

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

Исаак
источник

Ответы:

2

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

sysadmin1138
источник
There is a difference between 'valid' and 'it works'. В конечном счете, я думаю, что это самый разумный ответ, хотя я очень высоко оценил все обсуждения. Я бы сделал вывод, что одно-символьные имена хостов все еще технически недействительны, но на этом этапе работают практически повсеместно. (Точно так же подчеркивание запрещено, но по большей части работает.)
Исаак
11

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

sysadmin1138
источник
Хорошо, я прочитал бы это в RFC-1123, но я интерпретировал это как означающее, что спецификации, которые я прочитал в RFC-952, применимы, за исключением того, что цифра также допустима в качестве первого символа (как вы цитировали, она не изменяет запрет на односимвольные имена). Что касается корневых серверов, мне в какой-то момент сказали, что они являются каким-то особым исключением из правила.
Исаак
2

Поскольку имена хостов существовали еще до того, как кто-то задумывался написать о них RFC, я не вижу никакой причины, по которой имена хостов из одного символа должны внезапно стать «незаконными». Этот конкретный RFC потерял меня, когда заявил

Этот RFC является официальной спецификацией.

потому что RFC НЕ является стандартом. Даже не близко.

Несмотря на вышесказанное, следует отметить, что данный RFC был создан для того, чтобы относиться к относительно небольшой группе, а именно к Министерству обороны (предположительно, из США).

Джон Гарденье
источник
RFC по определению не является стандартом. «Запрос комментариев» никому не кричит «стандарт». Интересно, что им это сошло с рук в собственных документах.
Марк Хендерсон
1
В en.wikipedia.org/wiki/Domain_name_system#Internet_standards перечислены многие RFC, которые «определяют» протокол DNS. RFC-1123 (как упомянуто sysadmin1138) является одним из перечисленных и ссылается на RFC-952. По моему опыту, хотя RFC являются запросами, они становятся определениями, когда они принимаются.
Исаак
@Farseeker, я не говорю, что это так, но я всегда удивляюсь людям, большинство из которых должны знать лучше, которые цитируют RFC, как если бы они были высшим авторитетом по любому конкретному вопросу. Я уверен, что где-то есть RFC. ;)
Джон Гарденье
1
Некоторые RFC фактически являются стандартами - например, RFC 1034 и 1035 вместе составляют STD0013. Причина, по которой они называются «Запросы на комментарии», является исторической и, по сути, была связана с кучей низкосортных аспирантов еще в конце 60-х, которые не хотели ставить галочку над своим начальством (я слышал это лично из автор RFC 1).
Альнитак
2
@ Джон Я предлагаю вам прочитать RFC 2026. «Спецификации, которая достигает статуса стандарта, присваивается номер в серии STD при сохранении номера RFC». Я пишу документы IETF для своей повседневной работы.
Альнитак
1

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

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

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

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

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

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

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

CoreDump
источник
Из следующего параграфа в Разделе 11 RFC-2181: в 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. основном, потому что a.domain.tld действителен в DNS, не делает его действительным именем хоста. Конец Раздела 11 ссылается на Раздел 6.1.3.5 RFC-1123, который цитирует Раздел 2.1 самого себя и RFC-952, как обсуждалось в ответе sysadmin1138.
Исаак
Цитата в конце раздела 6.1.3.5 говорит о меньшем ограничении соглашения об именах, определенного в 952. Также 952 определяет таблицу хостов DOD, и я не совсем убежден, что она более актуальна, чем спецификации DNS.
coredump
Я думаю, что либерализация ограничений, упомянутых в конце 6.1.3.5, относится только к разрешению первого символа быть числом - это единственное изменение, упомянутое в разделе 2.1 того же RFC (который является разделом, к которому относится 6.1. 3,5 относится). Именно в этом разделе 2.1 определение из RFC-952 упоминается как определение допустимого имени хоста.
Исаак
Также проверьте RFC 920 и 921, который рассматривает миграцию от старого DARPA к доменным именам.
coredump
1

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

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

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

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

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

Альнитак
источник
1
Но в 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. не разумно ли интерпретировать это как означающее, что ваша цитата не полностью перекрывает текст из RFC-952?
Исаак
Это говорит об этом, но это явно неправильно. RFC 1123 также явно изменяет допустимую длину имени хоста.
Альнитак