Таблица хостов до рынка: кто уполномочил первый интернет-реестр?

Кратко

• Ранняя таблица хостов получила практический авторитет через ограниченную цепочку: ARPA заказала Network Information Center для ARPANET, SRI вела общий реестр, участвующие узлы предоставляли и потребляли информацию о хостах, а DCA позднее включила службу в операционную среду DoD.
• RFC 810 опубликовал предварительное условие о регистрации имён и адресов, используемых в отношении трафика, пропускаемого хостами DoD, но сохранившаяся спецификация не демонстрирует мониторинг, отклонение пакетов, санкции, показатели соблюдения или какое-либо конкретное заблокированное сообщение.
• Открытый массив документов не содержит полных ранних контрактов, файлов запросов по таблице хостов, спорных решений, результатов исправлений, записей о пересмотре, отчётов о правоприменении или средств правовой защиты, необходимых, чтобы установить ни неограниченное усмотрение NIC, ни публичный мандат, распространяющийся на любую внешнюю сеть.

8 марта 1974 года Network Information Center попросил все узлы ARPANET изменить локальную таблицу хостов. Инструкция содержалась вRFC 620, «Request for Monitor Host Table Updates», выпущенном Биллом Фергюсоном из Augmentation Research Center компании SRI. Сервисы NIC переехали наOFFICE-1, сетевой узел 53 в восьмеричной записи. Узел 2 осталсяSRI-ARC, но его псевдоним должен был статьARC; привычный псевдонимNICтеперь должен был указывать на узел 53. В уведомлении приводились точные записи для таблиц монитора TENEX, а узлы, работающие на других операционных системах, должны были внести аналогичные изменения.

RFC 620 фиксирует инструкцию, а не наблюдаемый случай её исполнения. В нём не назван ни отдельный оператор, выполнивший работу, ни узел, который этого не сделал, ни возникший простой. Тем не менее оператор — необходимая роль, подразумеваемая документом: кто-то на каждом узле должен был изменить локально используемое сопоставление способом, подходящим для данной операционной системы. Если таблица оставалась устаревшей, она продолжала связыватьNICс узлом 2 и могла увести попытку обращения по имени от предполагаемого сервиса NIC. Это следствие изменения сопоставления, но в RFC не сообщается ни о фактическом неудачном поиске, ни о неправильно направленном соединении.

Уведомление вскрывает административную структуру за, казалось бы, простым именем. SRI могла объявить новое соответствие, но объявление не переписывало каждую удалённую машину. Узел должен был получить инструкцию, интерпретировать её и изменить собственную систему. Совместное именование работало, когда поддерживаемый реестр, канал распространения и локальная реализация сходились.

25 марта 1974 годаRFC 627анонсировал более регулярный механизм распространения. Онлайновый ASCII-файл официальных имён хостов был доступен наOFFICE-1, чей адрес указывался как 43 в десятичной записи, что эквивалентно 53 в восьмеричной, как в RFC 620. NIC должна была поддерживать файл и еженедельно вносить дополнения и изменения. Каждый сетевой хост был обязан получать новую информацию по протоколу передачи файлов (FTP). Изменения, дополнения, исправления и замечания можно было направлять Элизабет «Джейк» Фейнлер по сетевой почте, телефону или через систему идентификации NIC.

Эти два мартовских документа не сохраняют полную цепочку от запроса до решения. Однако их можно объединить с более ранними и более поздними записями, чтобы получить минимальную составную реконструкцию, при условии, что даты в ней остаются раздельными.

В 1971 году хост выбирал предпочтительное официальное имя через своего представителя в соответствии с процедурой, предложенной вRFC 273. Представитель передавал выбор; документ не устанавливает, что технический представитель лично обладал полномочиями принимать все организационные решения за узел. Предложенная схема именования предполагала уникальность псевдонимов в сетевом сообществе и предусматривала обсуждение в случае выбора дублирующихся или необычно длинных имён. Она не определяла ни права вето NIC, ни теста на отклонение, ни окончательного правила принятия решений, ни пересмотра, ни апелляции.

В январе 1974 годаRFC 608описал официальное имя хоста как строку, получаемую в результате переговоров между хостом и NIC. В нём установлены ограничения на символы и форматирование, указан исходный файл Фейнлер в формате NLS и предложена периодическая генерация машиночитаемой ASCII-версии. Он не объясняет, чем завершались спорные переговоры и кто побеждал, когда обсуждение не удавалось.

В марте 1974 года RFC 627 установил доступный файл, еженедельное внесение обновлений, канал исправлений и обязанность каждого хоста получать новую информацию. Лишь в 1982 годуRFC 810прямо указал, что пользователь таблицы хостов DoD отвечает за преобразование её в любой требуемый локальный формат. Было бы неточно сжимать эти заявления 1971, 1974 и 1982 годов в один наблюдаемый порядок или приписывать каждый шаг одному и тому же должностному лицу.

Защитимая составная реконструкция поэтому скромна. Хост сообщал предпочтительное имя через представителя. Опубликованные соглашения определяли форму имени, ожидалась уникальность псевдонимов, а дублирующиеся или длинные варианты могли вызвать обсуждение. SRI вела исходный материал, из которого генерировала общий файл. Узлы забирали файл и включали его содержимое в свои локальные системы. К 1982 году обязанность пользователя выполнять локальное преобразование была сформулирована явно.

Что происходило, когда предложенное имя оставалось спорным, когда исправление оспаривалось или когда узел отвергал инструкцию, по одним процедурным RFC восстановить нельзя.

Это первая граница авторитета таблицы хостов. Общий реестр мог определять, какое имя распознаёт участвующая система, не решая, существовал ли сам компьютер, была ли проложена физическая линия или принята ли организация в сеть. Его последствия были операционными и иногда серьёзными для использования имён, но они не равнозначны контролю над всей связностью.

Четыре расходящиеся таблицы и доводы в пользу общего файла

Онлайновый файл хостов решал наблюдаемую проблему координации. В декабре 1973 годаRFC 606описал четыре доступные TENEX-системы —SRI-ARC,BBN-TENEX,USC-ISIиPARC-MAXC, — чьи сопоставления имён хостов и адресов различались. Ни одна не была полной, и автор полагал, что каждая в чём-то расходится с официальным списком.

Эти данные не следует раздувать до утверждения, что на каждом узле ARPANET была неточная таблица. Они устанавливают расхождения на четырёх названных системах. Даже этот ограниченный вывод достаточен, чтобы показать цену раздельного ведения. Человек, переходящий между этими машинами, мог получать разные ответы. Программа, написанная под один локальный набор, могла отказать при переносе на другой. Недавно добавленный или переименованный хост мог распознаваться на одном узле, но оставаться неизвестным на другом.

RFC 606 предложил централизованно генерируемый машиночитаемый файл, поддерживаемый NIC. В нём два ключевых факта записи — имя хоста и адрес хоста — отделялись от необязательных атрибутов, таких как статус хоста, поведение протоколов и псевдонимы. Автор предупреждал, что атрибуты не обязаны быть полными и не должны заменять переговоры по протоколам, устную передачу информации или другие способы выяснения свойств хоста. Предложение было намеренно конкретным: оно решало проблему несовместимых локальных списков, а не устанавливало всеобъемлющую конституцию участия в сети.

RFC 608 принял идею центрального файла и сообщил, что она получила поддержку управления ARPA по методам обработки информации. Фейнлер вела исходный материал в формате NLS компании SRI, а программа должна была периодически генерировать ASCII-версию для распространения. Первоначально генерируемые записи должны были содержать официальное имя, десятичный адрес хоста и статус. Прочие сведения можно было добавлять по мере поступления данных. Документ также допускал сетевой префикс для хостов вне ARPANET, что показывает: авторы уже рассматривали более широкое множество для сравнения, чем только хосты ARPANET.

При этом он не перечисляет все внешние хосты, фактически включённые в файл.

Различие между исходным материалом и распространяемой версией имело значение. NLS — это система SRI для поддержки структурированной информации. ASCII-версия предназначалась для получения и обработки разнородными хостами.SRI-ARCбыл организационным и вычислительным контекстом, из которого выходили многие из этих уведомлений, аOFFICE-1в марте 1974 года стала машиной, обслуживающей пользователей NIC и публикуемый файл хостов. В более поздних документах для хоста, предоставляющего таблицу DoD и службу имён, использовалось имяSRI-NIC. Эти обозначения отражают технические и организационные изменения; их нельзя рассматривать как взаимозаменяемые имена одной неизменной машины.

RFC 627 превратил предложение в анонсированную службу. Он рекомендовал хостам использовать официальные имена в своих мониторах и возлагал на каждый хост ответственность за получение файла. Псевдонимы были необязательны, и системам, предоставляющим преобразование имён в адреса, рекомендовалось, а не предписывалось их использовать. Документ давал каналы для дополнений и исправлений, но наличие канала не доказывает ни сроков, ни требуемых доказательств, ни средства правовой защиты при отказе в запросе.

Архитектура оставалась распределённой в точке использования. SRI вела эталонный файл, но удалённые узлы решали, когда его получить и как установить. Недавно исправленный эталон мог сосуществовать с устаревшими локальными копиями. Оператор мог дополнить официальный файл локальным псевдонимом. Человек, знавший числовой адрес, мог обойти отсутствующее имя. Таблица уменьшала несогласованность, не становясь сама подсетью с коммутацией пакетов.

Неверная запись всё же могла иметь ощутимые последствия. Программа, работающая по именам, могла направлять трафик на записанный адрес, а не на предполагаемую машину. Отсутствующая запись могла оставить ПО неспособным преобразовать запрошенное имя. Задержанное локальное обновление могло сохранять устаревший результат. Точное поведение зависело от локальной операционной системы и приложения. RFC не дают оснований утверждать, что любой пропуск приводил к разрыву соединения или что каждая неточная запись давала одинаковую ошибку.

Мартовский переезд иллюстрирует более узкий тезис. После переезда NIC наOFFICE-1узел, внедривший изменение из RFC 620, связывал псевдоним с узлом 53. Устаревший узел мог продолжать связывать его с узлом 2. Переезд службы SRI произошёл независимо от удалённой таблицы, тогда как полезность общего псевдонима зависела от того, приняли ли его на удалённых узлах. Реестр был значим, потому что другие машины действовали на его основе.

Имена начинались с хостов, а не с безграничного вето NIC

Общий файл не возник из устоявшегося правила, позволявшего NIC назначать любое имя по своему усмотрению. В дискуссии в RFC 1971 года зафиксированы существенные разногласия об именовании.

RFC 226распространил предложенный набор мнемоник и пригласил к возражениям. Последовали конкурирующие предложения. Одни участники предпочитали короткие позывные; другие хотели имена, сохраняющие институциональную и проектную идентичность. Дебаты не были лишь косметическими. Имена встречались в командах, документах и привычках пользователей. Поэтому правило именования распределяло не только символы, но и неудобства, и узнаваемость.

ВRFC 237NIC утверждала, что является логичным органом для поддержания стандарта именования, и предлагала назначать имена новым хостам после того, как Network Working Group утвердит синтаксис и текущий список. Это была институциональная инициатива оператора службы. Она свидетельствует о том, какой NIC хотела видеть свою роль, но не о том, что каждая подключённая организация или вышестоящий публичный орган приняли это притязание целиком.

RFC 273 стал ответом на неудачу предыдущих предложений добиться признания. В нём говорилось, что хосты через своих представителей должны сами выбирать официальные имена, возможно, с обсуждением, если выбраны дублирующиеся или слишком длинные имена. Хосты одного учреждения должны были использовать один и тот же институциональный мнемонический код. Псевдоним должен быть уникален в сетевом сообществе.

Формулировки устанавливают локальный выбор и возможность центрального обсуждения. Они не определяют, кто мог вынести окончательный отказ. Дублирование подрывало бы смысл общего псевдонима, но одна лишь техническая несовместимость не раскрывает административного средства решения. NIC могла убедить узел выбрать другое имя; мог вмешаться спонсор; узлы могли принять неформальную договорённость; или разногласие могло остаться нерешённым. Чтобы различить эти возможности, нужно полное дело.

RFC 289, выпущенный в декабре 1971 года, сообщил, что почти все узлы ответили желаемыми именами. Его название — «What We Hope Is An Official List of Host Names» — сохраняет предварительный характер этого упражнения. Формировавшийся список отражал запрос и ответы узлов в ограниченном сообществе ARPANET. Он не был ни односторонним частным изобретением, ни результатом всемирной публичной делегации.

Роль представителя (liaison) также требует осторожности. RFC 273 использовал представителей как канал, через который хосты выбирали и сообщали имена. Более позднийпутеводитель Computer History Museum по архивам SRI ARC/NICговорит, что технические представители, как правило, не имели полномочий выступать от имени администрации узла. В архивном путеводителе описано более позднее создание роли администратора хостов (Host Administrator), чей обладатель мог санкционировать действия узла. Поскольку путеводитель охватывает более длительный период, его нельзя просто спроецировать назад на каждый обмен 1971 года. Однако он предостерегает от отождествления «представителя» с руководителем учреждения.

Самое большее, что можно сказать с уверенностью: в опубликованной процедуре 1971 года исходный выбор делал хост, представитель был каналом связи, а NIC поддерживала общий результат. Синтаксис и ожидаемая уникальность ограничивали то, что могло работать в общем пространстве имён. Документы не раскрывают всеобъемлющей системы разрешения споров.

Эта ограниченная свобода действий всё же имела значение. Как только имя появлялось в документах и машиночитаемых файлах, пользователи в других местах могли на него полагаться. Хост мог сменить имя, но это создавало издержки для ПО, документации и локальных знаний. Стабильность стала источником практического авторитета. Центру не нужна была широкая юридическая власть, чтобы поддерживаемый им ответ было трудно игнорировать.

Контракт ARPA на услуги и передача полномочий DCA

Институциональная цепочка началась с федеральной исследовательской программы, а не с более широкого интернета.

ARPANET была конкретной сетью с коммутацией пакетов, созданной через Advanced Research Projects Agency в составе Министерства обороны США. ARPA финансировала исследовательскую программу, выбирала подрядчиков и поддерживала участвующие исследовательские центры. В 1972 году агентство стало Defense Advanced Research Projects Agency. Поэтому «ARPA» уместно для создания сети и ранней дискуссии об именовании, тогда как «DARPA» встречается в документах более позднего периода.

Отчёт о завершении ARPANET (ARPANET Completion Report), подготовленный в 1978 году, говорит, что Stanford Research Institute получил контракт на разработку и эксплуатацию Network Information Center для ARPANET. Работа началась одновременно с реализацией сети в 1969 году. В отчёте описана служба, которая вела списки участников и рассылки, архивировала технические документы, предоставляла информацию о ресурсах хостов, обеспечивала доступ к системе NLS компании SRI и поддерживала спецификации протоколов ARPANET.

Это устанавливает отношение спонсор—подрядчик. ARPA заказала информационную службу для сети и исследовательского сообщества, которое поддерживала. SRI была обязана выполнять всё, что требовал контракт, а ARPA имела соответствующее право требовать исполнения по контракту. Публичный отчёт не воспроизводит раннее техническое задание, поправки, стандарты приёмки, санкции, положения о данных или правила принятия решений по именам хостов. Поэтому он не может установить полное юридическое содержание этой обязанности.

Узлы, подключённые к ARPANET, были институционально разнородны. Среди них были университеты, исследовательские институты, правительственные лаборатории, военные объекты и частные подрядчики. Разнообразие правовых форм не делало каждый узел независимым публичным оператором. Многие участвовали через федеральное спонсирование, контракты или одобренные служебные отношения. В то же время отсутствие исходных документов узлов не позволяет утверждать, что каждая подключённая организация имела одинаковое контрактное условие о соблюдении требований к таблице хостов.

Наиболее сильное прямое описание передачи от ARPA в Defense Communications Agency является поэтапным и датированным. В отчёте о завершении описан меморандум ARPA–DCA, согласно которому управление ARPANET перешло к DCA 1 июля 1975 года. В нём также зафиксирован шестимесячный переходный период до 31 декабря 1975 года, в течение которого ARPA продолжала помогать DCA, пока DCA принимала на себя управление. Подробный план перехода был завершён к июню.

В отчёте говорится, что переданная сеть должна была работать как объект DoD, используемый для правительственных нужд. DCA должна была финансировать эксплуатацию и обслуживание через механизм распределения затрат с участием спонсоров ARPANET. Первоначально DCA предстояло заключить контракты с BBN и SRI на эксплуатацию сети, обслуживание и функции NIC. В отчёте сказано, что явно подразумевалась возможность привлечения DCA других подрядчиков позже, безусловно, после первого года.

Это свидетельство институциональной заменяемости на уровне выбора подрядчика. Оно не доказывает, что у DCA была полная переносимая копия всех записей NIC, неограниченные права на данные, созданные подрядчиком, проверенный пакет перехода или обеспеченное правовой защитой средство на случай любого сбоя службы. Заказчик может в принципе выбрать другого поставщика, но сталкиваться с серьёзными практическими препятствиями при передаче знаний сотрудников, ПО, архивов, текущих записей и отношений с узлами.

Публикация DCA 1978 года, индексируемая какARPANET Information Brochure, также называет 1 июля 1975 года датой передачи управления. Более поздний архивный путеводитель Computer History Museum представляет противоречивый ретроспективный рассказ: в нём говорится, что эксплуатация ARPANET была передана DCA в 1973 году и что контрактное финансирование DCA поддерживало NIC при SRI после 1974 года.

Противоречие должно оставаться видимым. Формальная хронология меморандума в отчёте о завершении даёт точную дату передачи и переходный период. Путеводитель даёт иные обобщённые даты, но не сам документ, который позволил бы их согласовать. В нём также говорится, что NIC стала отдельным проектом в 1973 году, — это другое институциональное изменение, нежели передача управления ARPANET. Без соответствующих контрактов и административных документов заявление об эксплуатации с 1973 года и заявление о финансировании после 1974 года нельзя свести в единую бесшовную хронологию.

После формальной передачи DARPA могла продолжать спонсировать исследования с использованием ARPANET, пока DCA управляла операционной сетью. DoD был вышестоящей государственной средой; DARPA и DCA выполняли в ней разные функции. SRI оставалась подрядчиком, выполняющим функции NIC, а не становилась самим правительством. Участвующие узлы эксплуатировали хосты. Представители хостов и более поздние контактные роли передавали информацию и инструкции. Различение этих ролей не позволяет спутать закупочные полномочия с универсальной властью.

Приём в ARPANET не был решением таблицы хостов

Таблица хостов фиксировала машины в операционной среде, но ведение этого реестра компанией SRI не делало SRI единственным органом, решающим, кто может присоединиться к ARPANET.

Справочник ARPANET Directory за декабрь 1978 годаописывал категории абонентов и процедуру получения услуги. Его рамки помещали приём и спонсирование в структуру управления сетью DCA. Потенциальный абонент должен был иметь приемлемую правительственную цель, спонсора и доступные мощности. Эти решения касались доступа к конкретной управляемой сети.

Различие принципиально. DCA могла администрировать право на абонентство в ARPANET. SRI могла вести справочник и информацию о хостах, используемые после приёма или вокруг него. Запись в таблице хостов могла быть необходима для удобного совместного использования, но фиксация хоста — не то же институциональное действие, что одобрение подключения организации, установка процессора интерфейсных сообщений (IMP), предоставление канала или разрешение на выполнение задачи.

Множество узлов ARPANET также не следует отождествлять с интернетом DoD. ARPANET была одной сетью. Интернет DoD был средой межсетевого взаимодействия, в которой ARPANET, пакетные радиосети, спутниковые системы и другие сети могли использовать интернет-протоколы и общую координационную информацию. Более широкий формирующийся интернет был ещё шире: меняющийся набор сетей, экспериментов и операторов, чьи правовые, контрактные и технические отношения не были единообразными.

К сентябрю 1981 годаRFC 790перечислял назначенные номера интернет-сетей для множества поименованных сетей, включая ARPANET, UCLNET, CYCLADES, TELENET, EPSS британского почтового ведомства, DATAPAC, TRANSPAC, LCSNET, TYMNET и ряд пакетных радиосетей, спутниковых, локальных и экспериментальных систем. Контактным лицом по назначению номеров сетей указан Джон Постел из Information Sciences Institute Университета Южной Калифорнии.

Список доказывает, что среда назначенных номеров выходила за пределы списка хостов ARPANET. Сам по себе он не устанавливает, что каждая названная сеть была в тот момент операционно взаимосвязана, независима от государственного спонсирования, коммерческой или не относящейся к DoD, либо подчинена процессу таблицы хостов SRI. Номер в документе о назначении — не полное описание контрактного статуса сети или её реального трафика.

Это также разделяет функции, которые более поздние истории иногда смешивают. Роль Постела по назначению номеров в USC-ISI касалась сетевых и протокольных параметров. SRI вела таблицу хостов и службу имён. DCA управляла ARPANET и заказывала службу NIC. DARPA продолжала спонсировать исследования. Ни один из этих фактов не делает какого-то одного участника единственным автором всего формирующегося интернета.

Поэтому выражение «первый интернет-реестр» нуждается в определённом сравнении. Таблица хостов не была первым справочником, который вёл компьютерная организация, и файл 1974 года не был реестром всемирного публичного интернета. Это был ранний общий машиночитаемый справочник имён и адресов в линии преемственности от ARPANET к интернету. К 1982 году его формат-преемник включал сети, шлюзы и интернет-адреса и описывался операторами как глобальная база имён и адресов хостов. Его историческое значение — в расширяющемся охвате и межорганизационной зависимости этого справочника, а не в доказанном мандате на все сети.

Правило DoD 1982 года: опубликованное предварительное условие, а не доказанное правоприменение

RFC 810 ознаменовал изменение охвата и институционального языка. Выпущенный 1 марта 1982 года Фейнлер, Кеном Харренстином, Зау-Син Су и Виком Уайтом из Network Information Center компании SRI International, он объявил, что прежняя таблица хостов ARPANET больше не отвечает потребностям сообщества DoD или межсетевого взаимодействия. Новый формат включал записи сетей, шлюзов и хостов, интернет-адреса, операционные системы и сведения о протоколах.

Таблица была доступна с хостаSRI-NICчерез FTP и через сервер имён хостов (Host Name Server). В RFC сервер назван службой, поддерживаемой NIC для ARPANET по поручению DCA. Обязанность по преобразованию прямо возлагалась на пользователя: тот, кто использует таблицу, должен привести её к требуемому локальному формату.

Его седьмое допущение содержало самый сильный операционный язык во всём корпусе записей о таблице хостов. Имена и адреса сетей, шлюзов и хостов DoD должны были согласовываться и регистрироваться в NIC до использования и до того, как хост DoD пропустит трафик. Это было опубликованное предварительное условие, регулирующее поведение хостов DoD. Оно связывало регистрацию с эксплуатацией более прямо, чем призыв 1974 года использовать официальные имена хостов.

Эта фраза не документирует правоприменение. RFC 810 не называет ни монитора, проверявшего регистрации, ни правила маршрутизатора, отклонявшего незарегистрированный трафик, ни санкции за несоблюдение, ни показателя соблюдения, ни конкретного заблокированного сообщения. Это различие важно. Спецификация может определять требуемое поведение, не доказывая, насколько последовательно операторы её реализовали.

Документ иначе относился к информации, не относящейся к DoD. На промежуточный период NIC должна была пытаться поддерживать аналогичную информацию о сетях и хостах вне DoD, если такая информация предоставляется и пока она нужна, в ожидании взаимодействующих серверов имён. Он не перечислял все фактически включённые записи вне DoD и не налагал то же явное предварительное условие на всех внешних операторов.

Новый формат также вводился поэтапно. RFC 810 назначил датой перехода 1 мая 1982 года. В мае прежний путьHOSTS.TXTвсё ещё содержал старую редакцию, а тестовый файл нового формата был доступен отдельно. В июне и июле основной путь содержал новый формат, тогда как материалы старого формата оставались доступны по другому пути. После 1 августа старый форматHOSTS.TXT, определённый в RFC 608, больше не поддерживался.

Такое перекрытие отделяет опубликованный замысел от немедленного всеобщего внедрения. У программ было время на адаптацию. Локальные системы могли оставаться на разных редакциях во время перехода. График показывает активное управление риском совместимости, но не доказывает, что каждый хост вовремя завершил преобразование.

RFC 811, выпущенный в тот же день, определил онлайновый сервер имён хостов (Hostnames Server). Программа могла запросить имя или адрес хоста или потребовать всю таблицу. Сервер мог возвращать записи хостов, шлюзов или сетей. Если запрошенное имя отсутствовало, определённая ошибка имела видERR: NAMNFD: Name not found:. Возможны были и другие ошибки, включаяTMPSYS— временный сбой системы и просьбу повторить попытку позже.

Эти семантики относятся к протоколу сервера SRI-NIC. Их не следует переносить на любой локальный резолвер, использующий загруженную копию. Локальный поиск по таблице без нужной записи мог завершиться неудачей, использовать дополнительное сопоставление, запросить пользователя или повести себя иначе в зависимости от системы. Отсутствие имени в локальной копии и ответNAMNFDот сервера — связанные, но не обязательно идентичные события.

RFC 811 описывал свою базу данных как расширение старого файлаHOSTS.TXTARPANET и называл централизованное администрирование временным решением на пути к децентрализованной распределённой службе преобразования имён и адресов. Это институциональное утверждение важно по двум причинам. Оно показывает, что SRI понимала службу как переходный механизм, а не постоянную архитектуру, и подтверждает, что состав и назначение таблицы расширились за пределы первоначального списка ARPANET. Само по себе оно не доказывает всеобщего охвата.

К началу 1980-х NIC всё чаще связывали со средой Defense Data Network, а более поздние исторические коллекции используют для службы имя DDN-NIC. Этот более поздний ярлык не следует переносить назад на контракт 1969 года или дискуссию об именах хостов 1971 года. SRI-ARC, SRI NIC, SRI-NIC и DDN-NIC описывают связанные, но хронологически различные организационные и хостовые контексты.

Что может показать архив — и чего не хватает

Серия RFC необычно богата предложениями, спецификациями и анонсами. Как запись отдельных административных дел она значительно слабее.

Архивный путеводитель Computer History Museum выделяет профильные коллекции: предложения и контракты NIC, отчёты о ходе работ, записи об именовании и адресации, таблицы хостов, материалы справочной службы, переписку и записи об официальных сетевых контактах. В нём сказано, что ранний контракт NIC не был разбит на задачи, а более поздние контракты стали детальнее. Также описаны технические представители, администраторы хостов, координаторы узлов и другие контактные лица, через которых проходили информационные или директивные сообщения.

Путеводитель устанавливает наличие, примерный предмет и структуру документов. Он не раскрывает содержание каждого контракта, письма или решения. Его описания не могут доказать, что запрос имени хоста был удовлетворён, отклонён или передан наверх тем или иным образом. Нужно вскрыть и сравнить сами документы.

Здесь не представлено ни одного полного дела с запросом, где были бы видны предложенное хостом имя, вопросы NIC, ответ узла и итоговое решение. Ни один сохранившийся случай не демонстрирует отказа NIC из-за дублирования, успешной апелляции, вмешательства спонсора или исправления. Ни один всеобъемлющий реестр не даёт сроков обработки или частоты ошибок. Контактные данные в RFC 627 доказывают, что канал исправлений существовал; они не доказывают, какие результаты через него достигались.

Отсутствующие контракты важны и по другой причине. Федеральный контракт может давать право на исполнение, не давая права собственности на каждую запись, титула на техническую систему или неограниченных прав на данные, созданные подрядчиком. Он может определять результаты работ, лицензии на данные, содействие при переходе и средства правовой защиты, но эти последствия зависят от его реальных условий.

Значительно более позднийанализ Government Accountability Office, посвящённый федеральным договорённостям об интернет-функциях, тщательно различал права на исполнение, права на использование данных, титул и собственность. Это заключение 2016 года касалось более поздних договорённостей по DNS и IANA и не восполняет отсутствующие условия контрактов SRI 1970-х годов. Его ценность здесь методологическая. Одно лишь федеральное финансирование не позволяет выводить любые имущественные или переходные права.

Отчёт о завершении поддерживает один более узкий вывод: DCA первоначально намеревалась сохранить SRI для функции NIC и могла позднее привлечь другого подрядчика. Это показывает предполагаемую заменяемость поставщика. Но не устанавливает, что замена могла произойти без задержек, споров о данных, переноса ПО, утраты институциональной памяти или перерывов в обслуживании.

Документы о внедрении отсутствуют и для условия о трафике из RFC 810. Чтобы перейти от опубликованного правила к доказанному правоприменению, нужны директивы DCA, программное обеспечение хостов, журналы аудита, отчёты об инцидентах, санкции или документально зафиксированный заблокированный поток. Без этих материалов статья может указать заявленный охват правила, но не его наблюдаемую силу.

Молчание должно трактоваться в обе стороны. Отсутствие опубликованной процедуры апелляции не доказывает, что не существовало неформальной эскалации. Телефонные звонки, сетевая почта, обмены в NLS и вмешательство спонсора могли разрешать споры без RFC. И наоборот, отсутствие опубликованных жалоб не доказывает, что все участники считали процесс легитимным или что каждое обновление было своевременным.

Возникающая неопределённость носит институциональный, а не только архивный характер. Если бы запросы обычно корректировались через прозрачное подтверждение узла, служба выглядела бы более канцелярской и кооперативной. Если бы NIC могла отклонять записи без объяснений и без проверки со стороны спонсора, тот же файл нёс бы иное управленческое значение. Открытые данные не поддерживают ни одну из крайностей как общее описание.

Альтернатива локальных списков и её реальные издержки

Исторически реалистичной альтернативой общему файлу была не современная система доменных имён, а практика, уже заметная до RFC 606: каждый узел вёл собственные сопоставления, получал изменения через личное общение и преобразовывал удалённую информацию под свою операционную систему.

При четырёх узлах это могло быть управляемо. Администраторы знали друг друга, разработчики протоколов регулярно встречались, и исправление могло передаваться по телефону, документу или сетевой почте. Узел мог принять локальный псевдоним, не дожидаясь центральной публикации. Если две организации часто общались, они могли поддерживать общую информацию в актуальном состоянии, даже когда центральная машина была недоступна.

Бремя сопровождения быстро росло. При десяти узлах, каждый из которых ведёт записи об остальных девяти, возможны до 90 направленных локальных сопоставлений. При ста узлах — до 9 900. Эти цифры описывают направленные копии на узлах, а не 90 или 9 900 отдельных двусторонних отношений. Число реально необходимых сопоставлений зависело бы от структуры общения, но каждый новый адресат создавал новые места, где информация могла устареть.

Добавление хоста или изменение адреса приходилось доводить до нескольких администраторов. Каждый применял бы его по своему графику и в локальном формате. Исправление могло быть подтверждено одним узлом, пропущено другим и искажено третьим. Операторам пришлось бы определять, какая у них редакция, сравнивать противоречивые сообщения и выяснять, вызван ли видимый сбой службы сетью, удалённым хостом или устаревшим сопоставлением.

RFC 606 даёт наблюдаемое предупреждение: четыре названные TENEX-системы уже имели неполные, расходящиеся таблицы. Он не количественно оценивает сбои, вызванные этими различиями. Само расхождение демонстрирует дублирование сопровождения и несогласованные ответы.

Общий источник снижал это бремя. Затронутый хост мог передавать информацию через один признанный канал. SRI могла генерировать одну редакцию. Узлы могли получать один и тот же файл и сверять своё локальное состояние с датированным эталоном. Инженер поддержки, расследующий расхождение, имел отправную точку.

Общий файл не устранял всех издержек распространения. Каждому узлу по-прежнему требовались хранилище, ПО для получения, локальное преобразование и процедура обновления. Еженедельная публикация вносила задержку между сообщённым изменением и его появлением в следующей редакции. Получение могло не удаться, если обслуживающий хост или сетевой путь был недоступен. Локальная установка могла отставать после успешного получения. Архитектура централизовала компиляцию, а не каждую операционную задачу.

Общий источник не гарантировал и истинности. SRI зависела от хостов и контактных лиц, предоставлявших точную информацию. Неверный адрес, присланный узлом, мог попасть в эталон. Правильное центральное обновление могло быть подорвано устаревшим локальным внедрением. Конфликт мог сохраняться, если процедура его разрешения была неясна. Эталон делал разногласия видимыми и уменьшал дублирование, но не отменял необходимость проверки.

Альтернатива локальных списков объясняет, почему организации следовали файлу NIC, не требуя теории неограниченной власти. Один поддерживаемый ответ дешевле потреблять, чем множество независимо реконструированных. ПО и документация становились надёжнее при использовании общих имён. Возникшая зависимость придавала поддерживаемому реестру операционную силу.

Общий реестр с более чем одним распространителем

Вторая реалистичная для того периода альтернатива сохраняла бы один канонический файл, распределяя хранение и получение шире.

Эта идея появилась в современных документах.RFC 623предложил, чтобы NIC хранила эталон, а другой хост поддерживал часто обновляемую вторичную копию. Его автор предложил UCSB и порекомендовал ежедневную синхронизацию. Целью была доступность: если хост NIC не мог отдать файл, пользователи могли обратиться к вторичной копии.

RFC 625принял принцип, что копию должны поддерживать более одного хоста, и приветствовал UCSB как перспективный вторичный узел. Он не согласился заменять FTP отдельным протоколом получения. RFC 627, выпущенный позже в марте, по-прежнему приглашал любой хост, желающий поддерживать вторичную копию, связаться с NIC.

Эти записи устанавливают предложенную и принятую схему репликации. Они не доказывают, что UCSB или другой хост эксплуатировал действующее зеркало. Подтверждение потребовало бы операционного уведомления, журнала сервера, архивной вторичной копии, руководства по хосту или более позднего отчёта. Предложение не следует переписывать как развёртывание.

Если бы такое вторичное хранилище работало, ему требовались бы ресурсы, соответствующие эпохе. Узлу нужны были хранилище для файла, персонал или автоматические процедуры получения обновлений и график, достаточно частый, чтобы редакция оставалась полезной. Пользователям нужно было знать, к какому хосту обращаться и как распознать последнюю каноническую версию. Вторичному узлу требовалось правило, что делать, если его локальная копия отличается от копии SRI.

Сбой мог затруднить согласование. Предположим, вторичный узел пропустил два обновления, пока SRI оставалась доступной, а затем вернулся со старой редакцией. Потребовалось бы соглашение о временных метках или последовательности, чтобы пользователи не путали доступность с актуальностью. Если SRI недоступна, а поступило спорное исправление, вторичный узел должен был бы знать, может ли он публиковать изменение или лишь продолжать отдавать последний подтверждённый эталон.

Репликация также оставляла нерешённым вопрос о полномочии вносить изменения. Зеркало могло распространять канонический файл, не решая, какими должны быть записи. Предоставление ему независимой правки создало бы возможность конкурирующих эталонов. Чтобы избежать этой проблемы, требовалось чёткое разделение между организацией, удостоверяющей свои факты, центром, согласующим общее пространство имён, распространителем, обслуживающим копии, и любым рецензентом, разбирающим споры.

Подтверждение узлами можно было усилить и без современной инфраструктуры. Перед еженедельной публикацией NIC могла бы направлять предлагаемое изменение затронутому представителю или уполномоченному контактному лицу узла. Датированное уведомление об изменении могло сопровождать генерируемый файл. Хранители вторичных копий могли бы сверять объявленные изменения с полученным файлом. Узлы могли бы сообщать о расхождениях применительно к конкретной редакции, а не к недатированной локальной копии.

Эти процедуры потребовали бы издержек. Контактным лицам пришлось бы отвечать. Исправления могли ждать подтверждения. Персоналу пришлось бы вести журналы и разбирать неотвеченные запросы. Хост, менявшийся быстро, мог счесть недельный цикл слишком медленным, а более частая публикация увеличивала вычисления, сетевой трафик и нагрузку на операторов. Формальная проверка могла повысить подотчётность, но и задерживать срочные исправления.

Переход подрядчика представлял более крупную проблему. Возможность DCA выбрать другого поставщика не гарантировала бесшовной замены SRI. Преемнику требовались текущий канонический файл, ПО, которое его генерирует, документация форматов и графиков публикации, открытые запросы, история исправлений, списки контактов, знания сотрудников и доступ к обслуживающей среде. Если контракт не определял права на передачу или использование данных, передача могла стать юридически и операционно трудной.

Сохранившиеся открытые документы не устанавливают, существовали ли эти переходные материалы как обеспеченные правовой защитой результаты работ. Они показывают, что рассматривался другой подрядчик, а не что действовал проверенный механизм передачи. Заменяемость на бумаге и непрерывность в эксплуатации — разные достижения.

Эта альтернатива проясняет управленческий выбор. Единый логический ответ не требовал единого физического распространителя. Каноническая редакция могла сосуществовать с зеркалами, подтверждением узлов, сохранёнными изменениями и новым поставщиком услуг. Каждое добавление перемещало бы издержки и ответственность, не устраняя необходимости в финальной координации.

Датированная цепочка полномочий, а не универсальный мандат

Между 1969 и 1983 годами авторитет таблицы хостов накапливался через серию разных отношений.

В 1969 году ARPA заказала Network Information Center для ARPANET. Это установило федерального заказчика, подрядчика SRI и определённую аудиторию службы. Но не сделало SRI представителем каждой компьютерной сети.

В 1971 году хостам предложили выбирать имена через представителей в рамках опубликованных соглашений. Дискуссия и отклики участников ARPANET обеспечили ограниченное признание в сообществе. Предложенная роль NIC была сужена локальным выбором, тогда как общее пространство имён по-прежнему требовало совместимых результатов.

В 1973-м и начале 1974 года расходящиеся локальные таблицы подтолкнули к созданию машиночитаемого общего файла. RFC 606 и 608 задокументировали предложение и структуру исходного материала. RFC 620 и 627 задокументировали конкретную инструкцию об изменении для всех узлов, доступный ASCII-файл, еженедельные обновления, обязанность локального получения и каналы исправлений. Они не документировали общего вето NIC или полной системы разрешения споров.

1 июля 1975 года, согласно меморандуму ARPA–DCA, описанному в отчёте о завершении, управление ARPANET перешло к DCA, после чего следовал переходный период до 31 декабря. DCA первоначально сохранила SRI для функций NIC и могла рассматривать другого подрядчика. Противоречащие утверждения путеводителя — о передаче эксплуатации в 1973 году и о финансировании после 1974 года — остаются неразрешёнными.

К 1978 году абонентская система DCA помещала приём в ARPANET в рамки государственного управления сетью, а не ведения таблицы хостов SRI. Это отделило полномочие принимать абонента от службы, которая фиксировала и распространяла информацию о хостах.

К 1981 году среда назначенных номеров перечисляла многие сети за пределами ARPANET, а назначение номеров сетей связывалось с Постелом из USC-ISI. Появление в этом списке не устанавливало, что каждая сеть имеет единое правовое или операционное отношение к DCA или NIC.

В марте 1982 года RFC 810 определил более широкую таблицу хостов интернета DoD и опубликовал предварительную регистрацию как условие для имён и адресов, используемых в отношении трафика, пропускаемого хостами DoD. Отдельная промежуточная обработка информации вне DoD обозначила границу. Правило было явным; его правоприменение остаётся недоказанным. Переход с мая по август дополнительно показал, что спецификация, переход и завершённая локальная реализация — разные этапы.

Сервер из RFC 811 сделал поддерживаемый ответ доступным через онлайновые запросы и описал центральную базу данных как временный мост к распределённому именованию. Эта служба усилила зависимость от SRI-NIC, признавая при этом, что архитектура не должна навсегда оставаться центральной.

Таблица хостов, таким образом, реализовывала свой самый сильный доказанный авторитет в трёх местах. SRI была обязана исполнением своему федеральному заказчику в рамках контракта, чьи полные условия недоступны. DCA могла издавать эксплуатационные требования для управляемой ею среды DoD. Участвующие машины и пользователи зависели от общего реестра для согласованной коммуникации по именам.

За пределами этих отношений охват таблицы возникал из интероперабельности и принятия. Внешняя сеть могла передавать информацию или использовать общий файл, потому что это облегчало коммуникацию. Такая зависимость имела последствия, но RFC 810 не описывал её как эквивалент условия DoD. Ни один рассмотренный документ не показывает, что всемирное сообщество делегировало SRI общие полномочия.

Таблица также не создавала всего, что фиксировала. Спонсор одобрял участие в сети; подрядчики и узлы поставляли машины и ПО; каналы и коммутаторы пакетов пропускали трафик; другие органы ведали номерами сетей; локальные системы потребляли опубликованные сопоставления. Реестр NIC помог сделать имя общеузнаваемым, но не создавал ни базовую организацию, ни физическое подключение, ни каждое числовое назначение.

Её практический авторитет тем не менее был существенным. Общий реестр, потребляемый многими машинами, может ограничивать поведение, даже если его создал не законодательный орган и не публичное членское объединение. Хост, желавший предсказуемого узнавания, имел основания следовать соглашениям об именовании. Узел, желавший актуальных ответов, имел основания получать общий файл. Хост DoD был адресован опубликованным предварительным условием регистрации. Внешнему оператору отклонение могло стоить дорого, потому что другие системы ожидали поддерживаемый ответ.

Что остаётся недоказанным, не менее важно. Сохранившиеся открытые данные не показывают, что NIC владела перечисленными адресами, могла произвольно исключать любую внешнюю сеть, налагала санкции на каждый несоблюдающий узел или превращала каждую отсутствующую запись в физическое отключение. Они не раскрывают полной структуры апелляций, средства исправления или иерархии пересмотра. Они не устанавливают переносимого государственного права собственности на все данные NIC.

Ранняя таблица хостов была авторитетна там, где пересекались закупки, управление сетью и зависимость машин. Она решала конкретную проблему: несовместимые локальные сопоставления делали общие имена ненадёжными. Централизованная компиляция упрощала распространение, сравнение и использование одного ответа. Это достижение объясняет, почему реестр обрёл силу до того, как имена и адреса стали рыночными активами.

Это не доказывает, что оператор реестра получил полномочия над каждой сетью, которую мог описывать реестр. Историческая цепочка поддерживает более узкий вывод: SRI вела заказанный государством справочник для спонсируемой сети, этот справочник встроился в операции интернета DoD, а более широкая зависимость расширила его практический охват. Полезность реестра сделала его влиятельным. Его публичный мандат остался неустановленным.