Чи дійсні однобуквені імена хостів?

RFC-952 (останнє речення пункту 1 під Припущеннями) забороняє односимвольні імена хостів, і я мав досвід ( більше 7 років тому влітку 2002 року), коли деякі служби відмовилися працювати з односимвольними іменами хостів (тому що такі назви були не відповідає стандартам), але я бачив ряд однозначних імен хостів, які використовувались протягом останніх кількох років. Чи дійсні односимвольні імена хостів зараз? (Якщо так, то яка правильна посилання на перевірку?)

редагувати (щоб консолідувати деяку інформацію з відповідей): різні аспекти DNS, здається, визначені у кількох RFC, включаючи 1035 , 1123 та 2181 . З розділу 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.
[ ... ]
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 забороняє односимвольні імена хостів.

Існує різниця між "дійсним" і "працює". Цілком можливо, що імена хостів не вважаються дійсними, якщо вони є окремими символами (моя попередня публікація не протистояла). Однак досить багато систем це дозволяють. Одна з основних систем, система AD / DNS Microsoft, має застарілі підстави для дозволу імен одного символу.

Старі шкільні імена 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 був правилом, тому клієнтам довелося зареєструвати своє ComputerName (перші 15 символів якого також є їх ім'ям NetBIOS) у домені DNS. Оскільки MS дозволяє односимвольним іменам NetBIOS реєструватись у DNS, це призвело до конфлікту з 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 НЕ є стандартом. Навіть близько не.

Незважаючи на вищевикладене, слід зазначити, що розглянутий РФС був створений для відновлення відносно невеликої групи, а саме до Міністерства оборони (імовірно, США).

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

Розділ 3 RFC 1034 говорить:

Простір доменних імен - це структура дерева. Кожен вузол і лист на дереві відповідає набору ресурсів (який може бути порожнім). Доменна система не робить різниці між використанням внутрішніх вузлів та листків, і ця примітка використовує термін "вузол" для позначення обох.

Кожен вузол має мітку, яка дорівнює нулю до 63 октетів. Вузли братів можуть не мати однакової мітки, хоча та сама мітка може використовуватися і для вузлів, які не є братами. Одна мітка зарезервована, і це нульова (тобто нульова довжина) мітка, що використовується для кореня.

І в розділі 11 RFC 2181 ми маємо пояснення щодо іменування кожного вузла адреси:

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

Отже, у світлі специфікацій DNS ви можете мати a.domain.tld

Як ви визначили, RFC 1123 не є цілком зрозумілим у цьому питанні.

У розділі 2.1 сказано:

Хост-програмне забезпечення ОБОВ'ЯЗКОВО обробляє імена хостів до 63 символів і ДОЛЖНІ обробляти імена хостів до 255 символів

Оскільки цей текст фактично повністю перекриває текст із RFC 952, слід також вважати, що будь-яка довжина до 255 символів є законною.

На жаль, ще в 1989 р. Інтернет-чернетки не отримали неймовірно ретельного огляду, який вони отримують зараз, тому двозначність, ймовірно, просто не помічена.