Кратко
- RFC 920 отвечал не только на вопрос, какие имена можно поставить после корневой точки. Он связывал каждую категорию с администратором, регистрационной ролью и процедурой допуска.
- ARPA объявлялась временной; GOV, EDU, COM, MIL и ORG составляли организационные категории. Домены стран и многоорганизационные домены были предусмотрены, но еще не учреждены.
- Более 500 узлов было общим ожиданием для домена верхнего уровня. Ориентир свыше 50 узлов для второго уровня RFC называл очень мягким и допускал исключения для крупных организаций.
Пятьсот — ожидание, пятьдесят — рекомендация
Разница между 500 и 50 узлами помогает прочитать RFC 920 без превращения его правил в механический тест. Документ, выпущенный Джоном Постелом и Джойс Рейнольдс в октябре 1984 года, говорил, что домену верхнего уровня потребуется специальное разрешение и что в общем случае такое разрешение будет даваться для ожидаемого масштаба свыше 500 узлов. Для доменов второго уровня ориентир был выше 50 узлов, но авторы прямо назвали это требование «очень мягким»: крупный университет или корпорация могли иметь всего несколько узлов. И никто не обязан был создавать отдельный домен только потому, что число узлов перешло границу.
Такой язык оставлял пространство для суждения. Численность помогала оценить масштаб, но сама по себе не решала, кто получит имя. Нужно было определить место заявителя в перечне категорий, назначить ответственного администратора, обеспечить надежную службу доменных имен и пройти регистрацию у вышестоящей стороны. Именно эти условия, а не две цифры изолированно, составляли процедуру допуска.
RFC 920 был официальным заявлением политики Internet Activities Board и DARPA для создания доменов в ARPA-Internet и исследовательском сообществе DARPA. Он уточнял требования ранее опубликованного плана RFC 881 и дополнял техническую линию RFC 882 и RFC 883 ограниченным набором доменов верхнего уровня. Это не была универсальная конституция для всех сетей: авторитет документа был прямо связан с указанной средой. Но внутри этой среды перечень уже распределял право просить о новой ветви.
| Позиция в начальном перечне | Имя или категория | Что было указано в 1984 году |
|---|---|---|
| Временная | ARPA | Имена действующих узлов ARPA-Internet; зона должна была со временем исчезнуть |
| Организационные категории | GOV, EDU, COM, ORG | Администратор — DARPA, регистрационный агент — NIC |
| Военная категория | MIL | Администратор — DDN-PMO, агент — NIC |
| Страны | Англоязычные двухбуквенные коды ISO alpha-2 | Домены стран еще не были учреждены |
| Несколько организаций | Отдельное имя не назначено | Ни одного домена такого типа еще не существовало; международная группа могла претендовать на него, если не вписывалась в другие категории |
Важное различие здесь — между разрешенной категорией и состоявшейся регистрацией. RFC 920 не утверждал, что все ветви уже были заполнены. Он прямо отмечал отсутствие доменов стран и многоорганизационных доменов. Даже для перечисленных названий полномочия различались: DARPA отвечала за ARPA, GOV, EDU, COM и ORG, тогда как MIL относилась к DDN-PMO. Network Information Center (NIC) выступал агентом и регистратором, но документ не считал желательным, чтобы NIC навсегда управлял всеми доменами верхнего уровня.
Значит, название вроде COM не было просто удачным ярлыком. Для нового домена верхнего уровня требовались специальное разрешение и регистрация в реестре доменных имен NIC. Для нижних уровней действовала цепочка: заявитель обращался к администратору непосредственно верхнего домена или к назначенному им ответственному лицу. Тот должен был убедиться, что условия выполнены, прежде чем выдать разрешение. Часть работы можно было передать администратору поддомена, но ответственность за более крупную ветвь оставалась у вышестоящего администратора.
Предусмотренное исключение для группы нескольких организаций показывает пределы любой фиксированной классификации. Крупный международный союз, который нельзя было легко отнести к одной из категорий, мог претендовать на место на верхнем уровне. В качестве гипотезы авторы приводили консорциум CSNET. Пример объяснял, зачем нужна отдельная категория для объединения организаций; он не доказывает, что CSNET получил такой домен. В том же документе сказано, что многоорганизационные домены еще не были учреждены.
Поэтому не следует смешивать иллюстрацию допустимого случая с записью о состоявшемся решении или переносить сюда историю доступа, стоимости и почтовых связей CSNET.
Число узлов было лишь одним из признаков способности поддерживать домен. RFC требовал назначить человека, который координировал бы вопросы домена, обладал техническими знаниями и полномочиями устранять проблемы и мог отвечать на жалобы, когда поведение узла затрагивало системы за пределами его домена. Служба имен должна была оставаться надежной. Два независимых сервера на разных машинах и отдельных источниках питания приводились как один из способов избежать общего отказа; сотрудничество с другим доменом или использование стороннего сервиса также допускалось.
Требовалась работоспособная ответственность, а не единственная предписанная схема оборудования.
Для ARPA было оговорено отдельное временное условие. Это имя возникло из истории развития системы и, по замыслу RFC 920, должно было исчезнуть. Хостам ARPA предлагалось заранее устроить переход в другой домен. Узлы DDN, не переходившие на новую службу имен, могли пока использовать файл HOSTS.TXT, который поддерживал NIC; авторы при этом ожидали, что и их имена позднее изменятся. Это инструкция и прогноз 1984 года, а не свидетельство того, что каждый узел выполнил переход или что ARPA исчезла в конкретную дату.
Позднейший RFC 1032, руководство для администраторов доменов 1987 года, описывал уже другой административный этап. В нем NIC фигурировал как регистратор и распорядитель корневой зоны, а организации CSNET и UUCP выступали посредниками: рассматривали заявки своих участников и передавали сведения NIC. Перечень к тому времени включал NET и домены стран. Этот снимок показывает, как регистрационная работа могла быть организована позднее; он не превращает каждое предложение RFC 920 в уже выполненный факт.
Первый список RFC 920 был не прогнозом того, какие окончания окажутся популярными. Он связывал ограниченные категории с ответственными администраторами, оставлял место для организаций, не помещавшихся в стандартные рамки, и задавал порядок, по которому новая ветвь получала разрешение. В 1984 году вопрос «сколько у вас узлов?» был только началом рассмотрения. Не менее важными были вопросы «к какой категории вы относитесь?» и «кто берет на себя ответственность за имя и службу?».
Источники
- RFC 920 — Domain Requirements
- RFC 881 — The Domain Names Plan and Schedule
- RFC 882 — Domain Names: Concepts and Facilities
- RFC 883 — Domain Names: Implementation and Specification
- RFC 1032 — Domain Administrators Guide
Эти соседние документы проверялись, чтобы ограничить тему; их более позднее состояние не переносится назад, в 1984 год.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

