Вопросы Теги

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

Изучите NAS dirtrobution такой, имеет FreeNAS (На основе FreeBSD) или OpenFilter (На основе Linux). Они действительно делают совместно использующие файлы простыми и даже помогают с, создают резервную копию.

Я лично использовал FreeNAS, дома обслуживающий NFS, Samba, iSCSI (для VMware) некоторое время теперь.

14
задан 20 July 2010 в 21:34
5 ответов

Существует различие между 'допустимым' и 'оно работает'. Совершенно возможно, что имена хостов не считают допустимыми, если они - отдельные символы (мое более раннее сообщение, не противостоящее). Однако довольно много систем действительно позволяет им. Одна главная система, система AD/DNS Microsoft, имеет причину прежней версии разрешения односимвольных имен.

Олдскульным именам NetBIOS позволяют быть 1 - 15 символами в длине. Эта спецификация была разработана независимо от RFC952, она базируется вокруг другого файла, названного lmhosts, таким образом, она работает. Проблема возникла, когда Microsoft отъехала NetBEUI (на самом деле NBF, Протокол кадров NetBIOS) и на 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-строги, которые не разрешают его.

2
ответ дан 2 December 2019 в 21:08

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

11
ответ дан 2 December 2019 в 21:08
  • 1
    Хорошо, я считал, что в RFC 1123, но я интерпретировал его, чтобы означать, что спецификации я читал в RFC 952, применяются, за исключением того, что цифра также допустима как первый символ (когда Вы заключили в кавычки, он не изменяет запрет на односимвольные имена). Относительно корневых серверов, мне сказали в какой-то момент, что они были некоторым специальным исключением из правила. –  Isaac 20 July 2010 в 05:11

Поскольку имена хостов были вокруг, прежде чем любой даже думал о записи RFC о них, я не вижу причины, односимвольные имена хостов должны внезапно стать "недопустимыми". Тот конкретный RFC потерял меня, когда он указал

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

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

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

2
ответ дан 2 December 2019 в 21:08
  • 1
    RFC по очень определению не является стандартом. "Запрос на Комментарии" точно не кричит "стандарт" никому. Интересный, что они вышли сухим из воды в своих собственных документах. –  Mark Henderson♦ 20 July 2010 в 05:48
  • 2
    en.wikipedia.org/wiki/Domain_name_system#Internet_standards перечисляет много RFCs, которые "определяют" протокол DNS. RFC 1123 (как упомянуто sysadmin1138) среди перечисленных, и он ссылается на RFC 952. Это был мой опыт, что, в то время как RFCs являются запросами, они становятся определениями, когда они приняты. –  Isaac 20 July 2010 в 06:56
  • 3
    @Farseeker, я не говорю, что он имеет место здесь, но я всегда удивляюсь людьми, большинство кого должно знать лучше, кто заключает RFCs в кавычки, как будто они - окончательные полномочия на каком-то конкретном предмете. Я вполне уверен существует RFC об этом где-нибудь. ;) –  John Gardeniers 20 July 2010 в 06:58
  • 4
    Некоторые RFCs на самом деле являются стандартами - RFCs 1034 и 1035 вместе, например, включает STD0013. Причина их называют "Запросами на Комментарии", является исторической, и в сущности имела отношение к набору низкосортных поствыпускников назад в конце 60-х, не желая убрать галочку в их начальниках (я слышал что лично прямо от автора RFC 1). –  Alnitak 20 July 2010 в 10:49
  • 5
    @John, я предлагаю Ваше чтение RFC 2026. "Спецификации, которая достигает состояния Стандарта, присваивают номер в серии STD при сохранении ее числа RFC". Я пишу документы IETF для своего дневного задания. –  Alnitak 21 July 2010 в 10:42

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

Разделите 3 из RFC 1034, говорит:

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

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

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

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

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

1
ответ дан 2 December 2019 в 21:08
  • 1
    Из следующего абзаца в Разделе 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. –  Isaac 20 July 2010 в 17:55
  • 2
    Цитата на конце раздела 6.1.3.5 переговоров о меньшем количестве ограничений на соглашение о присвоении имен определяется на 952. Также эти 952 определяют таблицу хостов DOD, и я не полностью убежден, что это более релевантно, чем спецификации DNS. –  coredump 20 July 2010 в 20:47
  • 3
    я думаю, что либерализация ограничений, упомянутых в конце 6.1.3.5, относится только к разрешению первого символа быть числом - это - единственная модификация, упомянутая в разделе 2.1 из того же самого RFC (который является разделом, к которому 6.1.3.5 относится). Именно в том разделе 2.1 на определение от RFC 952 ссылаются как являющийся определением легального имени хоста. –  Isaac 20 July 2010 в 22:28
  • 4
    Также проверьте RFC 920 и 921, который рассматривает миграцию от старого DARPA до доменных имен. –  coredump 21 July 2010 в 00:24

Поскольку Вы определили, RFC 1123 не абсолютно ясен по этой проблеме длины.

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

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

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

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

1
ответ дан 2 December 2019 в 21:08
  • 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? –  Isaac 21 July 2010 в 14:02
  • 2
    Это говорит это, но это явно неправильно. RFC 1123 также явно изменяет допустимую длину имени хоста. –  Alnitak 21 July 2010 в 17:54

Теги

Похожие вопросы