До того как WHOIS стал доказательством: хрупкая сила контактных записей

Кратко

• RFC 812 определил NICNAME/WHOIS в 1982 году как человекочитаемый справочник для поиска пользователей сети. RFC 954 расширил круг искомых лиц в 1985 году, однако ни одна из спецификаций не делала возвращаемое имя, хэндл, организацию, хост или контактные поля доказательством законных прав или текущего оперативного контроля.
• Четыре семейства записей развивались разными путями: записи личного справочника, контакты хостов и сетей DDN, регистрации доменов и их публичные отображения в WHOIS, а также записи реестра номерных ресурсов. Общий интерфейс запроса не превращал их в единую систему титулов.
• Инцидент декабря 1990 года даёт прямое свидетельство оперативной опоры на записи и ограниченной атрибуции ответственности: запись о сети в реестре DDN NIC направляла пострадавшие площадки и CERT/CC к учреждению, тогда как журналы, локальное администрирование и непосредственное расследование оставались необходимыми для идентификации машины и оператора.
• Спор февраля 1996 года вокруг регистрации CLUE.COM даёт завершённый случай административного статуса в базовой процедуре регистрации Network Solutions. Зафиксированный регистрант получил уведомление, оспорил угрожающее изменение и добился судебного запрета, сохранившего регистрацию. Судебный материал не показывает, что публичный запрос WHOIS самостоятельно создал этот статус.
• Судебное разбирательство Kremen документирует другое столкновение в октябре 1995 года: Network Solutions изменила свою авторитетную базу регистраций после получения поддельного распоряжения, что вызвало практические последствия использования. Публичный WHOIS мог отражать изменённое состояние, но доказательства не показывают, что публичный запрос вызвал изменение или наделил правом собственности.
• К 1996 году данные регистрации и переназначения номерных ресурсов были предписаны как входные данные для оперативных контактов и решений о дополнительном выделении. Тем не менее RFC 2050 требовал сопровождающей документации, защищал конфиденциальные материалы, обозначенные заявителем, и предусматривал пересмотр через иерархию реестров. Ни один рассмотренный здесь случай не показывает, что публичная строка номерного ресурса сама по себе решала вопрос о правах.

Читаем схему, прежде чем вчитывать в неё авторитет

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

RFC 812, написанный Кеном Харренстином и Виком Уайтом и датированный 1 марта 1982 года, описывал NICNAME/WHOIS как транзакционный сервер запросов и ответов на машине SRI-NIC. Он предоставлял пользователям ARPANET сетевой справочник по поручению Агентства оборонных коммуникаций. Пользователь отправлял одну командную строку, получал ответ и отключался. Ответ предназначался для чтения человеком, а не для автоматической интерпретации.

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

RFC 954, написанный К. Харренстином, М. К. Стал и Э. Дж. Фейнлер и датированный октябрём 1985 года, сохранил порт 43 и архитектуру «один запрос — один ответ». Он описывал сервис как справочник пользователей Интернета и снова говорил, что его вывод предназначен для чтения человеком. Круг искомых был шире: зарегистрированные люди и почтовые ящики, сетевые организации, узлы DDN и связанные хосты, а также зарегистрированные пользователи терминального доступа MILNET.

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

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

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

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

Поэтому пять компонентов должны оставаться раздельными:

1. базовая база регистрации или идентификации учреждения;
2. публичный ответ WHOIS, формируемый из этой базы;
3. процедура добавления, изменения или удаления регистрации или контакта;
4. операционные системы, связанные с идентификатором, включая администрирование хостов, маршрутизацию и делегирование DNS;
5. договоры, переписка о выделении, организационные назначения, согласия и юридические записи вне базы данных.

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

Рассматриваемая здесь доказательственная лестница:

удобство справочника -> оперативная опора -> атрибуция ответственности -> административный статус -> вывод, подобный праву

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

Имя и хэндл: запись личного справочника

Первое семейство записей было справочником людей.

Для чего предназначались поля

Поле имени отвечало на простейший вопрос: кого ищут? Хэндл делал этот ответ более стабильным внутри базы данных. Пользователь мог искать широко, а затем выбрать конкретную запись по её хэндлу. Другие записи могли ссылаться на хэндл, не воспроизводя все контактные поля.

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

Это не было удостоверением личности. RFC 812 и RFC 954 не описывали документальное подтверждение личности, подпись, связанную с хэндлом, или внешний орган, удостоверяющий каждую принадлежность. Хэндл устанавливал преемственность в базе данных яснее, чем преемственность в занятости, обязанностях или правоспособности человека.

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

Подача, обновление и аутентификация

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

Сохранившиеся спецификации поддерживают следующий ограниченный аудит:

• Податель и происхождение:информация поступала от лица, которое искало регистрацию или обязано было зарегистрироваться в NIC.
• Право обновления:RFC не устанавливают исчерпывающего правила о том, кто мог заменить существующую запись о человеке.
• Аутентификация:в публичных документах протокола не указан единый метод проверки личности.
• Исправление:каналы помощи и регистрации существовали, но RFC не описывают процедуру оспариваемых исправлений.
• Замена и текущее время:публичный ответ представлял текущий ответ базы данных; спецификации не определяют историю времени вступления в силу для каждой записи.
• Хранение истории:публичная последовательность прежних значений не определена.
• Разрешение конфликтов:RFC не объясняют, как персонал решал бы несовместимые требования к одной и той же личной записи.
• Границы приватности:личная контактная информация намеренно раскрывалась, потому что поиск людей был исходной целью сервиса.

«Неизвестно» не означает «не существует». Внутренняя переписка или практика персонала могли обеспечивать контроль, который RFC не документировали. Обоснованный вывод: эти меры не были частью доказательств, предъявляемых пользователю публичного ответа.

Какую ступень поддерживает это семейство

Запись личного справочника напрямую устанавливает удобство справочника. В 1982 и 1985 годах идентифицированным пользователем был участник ARPANET или DDN, искавший человека, почтовый ящик, организацию или связь с хостом. Решением было, куда направить сообщение или запрос. Конкурирующими источниками были справочник работодателя, учётная запись хоста, список площадки, телефонный контакт или подтверждение от самого человека или учреждения.

Рассмотренные здесь источники не документируют случай до 1997 года, когда само наличие личного хэндла NIC решало вопрос о законном праве, организационных полномочиях или техническом контроле. Устойчивость поля могла провоцировать такие выводы, но его документированная функция оставалась поиском.

Хост и сеть: запись оперативного контакта DDN

Второе семейство связывало людей с машинами, сетями и определёнными оперативными ролями. Здесь запись начала нести нечто большее, чем доступность.

От принадлежности к обязанности действовать

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

Современные источники определяют эту ответственность.Руководство администратора домена, RFC 1032, датированное ноябрём 1987 года, отличало администратора домена от технических контактов и контактов зоны. Ожидалось, что администратор координирует домен, управляет им и обладает полномочиями действовать или делегировать. Технические контакты и контакты зоны поддерживали программное обеспечение и данные серверов имён и работали с техническим персоналом в других местах.

RFC 1173, датированный августом 1990 года, описывал обязанности менеджеров хостов и сетей. Это была явно информационная сводка «устной традиции» Интернета, а не стандарт IAB. Даже с этой оговоркой его содержательный тест показателен. Он требовал регистрации ответственных лиц подключённых сетей в соответствующем NIC и поддержания их данных в актуальном состоянии. Ожидалось, что сетевой менеджер обладает доступом к управлению системой или полномочиями отключать, разъединять или прекращать пересылку трафика от некорректно работающей системы. Менеджер хоста точно так же должен был обладать полномочиями, доступом и инструментами, необходимыми для управления хостом.

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

Путеводитель по записям SRI ARC/NIC 2011 годадаёт ретроспективную карту коллекции и выделяет материалы о технических связных, администраторах хостов, координаторах узлов и других контактных группах. Он помогает найти соответствующие записи; он не рассматривается как современное доказательство того, зачем была создана каждая роль и какими именно полномочиями обладал её носитель. Эти утверждения требуют документов периода, таких как RFC 1032, RFC 1173, директив, регистрационных материалов и оперативных отчётов.

Датированный отчёт о ведении контактных файлов

Более точная оперативная запись сохранилась в работе Мэри К. СталDescriptions of NIC Tables and Lists(«Описания таблиц и списков NIC») — финальном отчёте от 5 апреля 1991 года. Центр сетевых информационных систем SRI International подготовил отчёт для Агентства оборонных коммуникаций по контракту DCA200-90-C-0027, проект SRI ECU 1050, CDRL № 027. Он фигурирует в коллекции Музея компьютерной истории под названиемDefense Communication Agency materials, 9 of 13.

Отчёт выделяет несколько различных производных файлов, а не единый недифференцированный файл WHOIS.

Раздел 3.1, стр. 7 отчёта, описывает файлы администраторов хостов MILNET. Их данные извлекались из базы данных NIC WHOIS. Первоначальная информация поступала из Network Change Directives, после чего хостмастер NIC ежемесячно запрашивал исправления у администраторов хостов. Производный файл генерировался еженедельно.

Раздел 3.7, стр. 10 отчёта, описывает файл, организующий администраторов хостов по сетевым адресам. Там же говорится, что исходные данные поступали из Network Change Directives и поддерживались в актуальном состоянии ежемесячными онлайн-запросами на исправления. Файл генерировался еженедельно.

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

Для записей хостов и сетей DDN аудит становится более конкретным:

• Податель и происхождение:исходная информация о хосте могла исходить из Network Change Directives; более поздние изменения — от признанных администраторов хостов, координаторов узлов или сетевого персонала.
• Право обновления:держатели ролей должны были подавать исправления, а хостмастер их запрашивал. Отчёт не определяет всех проверок, применявшихся, когда новый корреспондент заявлял о замене существующего держателя роли.
• Аутентификация:установленная роль и канал переписки создавали процедурное доверие, но отчёт не описывает единой системы проверки личности или аутентификации сообщений для всех обновлений.
• Исправление:ежемесячные запросы и добровольные подачи обеспечивали повторяющиеся пути исправления.
• Замена и текущее время:еженедельно перегенерируемые файлы и версии на уровне файлов показывали циклы публикации, а не обязательно дату вступления в силу каждого внешнего организационного изменения.
• Хранение истории:отчёт описывает текущие производные файлы и их генерацию. Он не устанавливает публичной, полной, по записям последовательности заменённых контактов и причин.
• Разрешение конфликтов:хостмастер занимал интерпретирующую позицию, но отчёт не описывает общей процедуры разрешения споров между претендентами на одну и ту же роль.
• Границы приватности:некоторые оперативные производные файлы содержали обширные личные и ролевые контактные данные. Эти детали здесь не воспроизводятся.

Система ведения была структурирована. Она не была эквивалентна публично проверяемой цепочке аутентифицированных доказательств. Текущая запись могла отставать от кадровых изменений без чьего-либо недобросовестного действия.

Оперативная опора и атрибуция ответственности в декабре 1990 года

Реальный инцидент даёт самое ясное продвижение до 1997 года за пределы предписанного использования.

В докладе, представленном на симпозиуме USENIX Security в 1992 году,Алессандро Берни, Паоло Франки и Джой Марино описали инциденты безопасности в Интернете в Италии. В их описании две площадки наблюдали попытки вторжения, связанные с сетью в Италии, и связались с CERT Coordination Center. Во время реагирования база данных DDN NIC WHOIS связывала сеть с Миланским университетом.

Доказательственные элементы можно изложить, не раскрывая исторические контактные данные:

• Дата:декабрь 1990 года, задокументирована в докладе 1992 года.
• Субъекты действия:пострадавшие площадки и CERT/CC.
• Использованная запись:сетевая ассоциация и контактная информация DDN NIC.
• Решение:какому учреждению следует направить первоначальное сообщение об инциденте и попросить провести расследование, прежде чем операторы рассмотрят изоляцию сети.
• Конкурирующие источники истины:системные и пакетные журналы, маршрутная информация, фактическое администрирование затронутой машины, локальные институциональные записи и прямое подтверждение.
• Результат:запрос идентифицировал релевантное учреждение и инициировал контакт, но ответственный администратор машины не был установлен немедленно, и связь оставалась затруднённой.

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

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

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

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

Организация, домен, контакты и серверы: доменная запись

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

Организация и домен

RFC 1032 предписывал администратору домена подавать регистрационный опросник и описывал администратора как ответственного за актуальность данных домена. Его раздел о проверке говорил, что WHOIS может использоваться для просмотра организации, связанной с доменом, доменного имени, административных, технических и зональных контактов, а также перечисленных серверов имён.

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

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

Следовательно, поля нужно читать раздельно:

• Организация:субъект, представленный в заявке на регистрацию.
• Административный контакт:лицо, ответственное за политику или организационную координацию.
• Технические и зональные контакты:лица, ответственные за работу серверов имён и связанные данные.
• Серверы имён:системы, которым предписано авторитетно отвечать за домен.
• Отображение в WHOIS:человекочитаемое представление регистратором зафиксированных фактов.
• Делегирование DNS:оперативное размещение домена в иерархической системе имён.

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

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

Исправление доменов в записи DDN 1991 года

В отчёте Стал от апреля 1991 года доменному контактному файлу приписывается конкретное происхождение. Раздел 3.8, стр. 10 отчёта, гласит, что производный файлDOMAIN-CONTACTSчерпал информацию из заявок на регистрацию доменов, обработанных хостмастером NIC, и из исправлений, поданных администраторами доменов. Исходные данные хранились в базе данных NIC WHOIS, а контактный файл генерировался еженедельно.

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

Отчёт подтверждает определённый путь исправлений, но оставляет другие вопросы открытыми:

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

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

Рабочий процесс запросов InterNIC 1993 года

RFC 1400, датированный мартом 1993 года, документировал переход услуг регистрации non-DDN к InterNIC. С 1 апреля 1993 года WHOIS InterNIC должен был содержать информацию об IP-адресах, доменах, номерах автономных систем и отдельных точках контакта, связанных с активными узлами. Общий охват личного справочника перестал быть основным населением центральной регистрационной службы.

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

Номер заявки раскрывал статус запроса, а отображение WHOIS могло нести дату последнего обновления.

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

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

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

Для доменного рабочего процесса 1993 года:

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

Ограниченное сравнение из RFC 1591

RFC 1591, датированный мартом 1994 года, касался структуры DNS и делегирования. Он полезен только как домен-специфичное сравнение.

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

В спорах о правах на имя RFC 1591 ограничивал роль регистрационного органа предоставлением контактной информации и говорил, что регистрация не создаёт статус товарного знака. Он также предусматривал пересмотр, когда стороны не могут достичь согласия.

Датированными субъектами действия были IANA, менеджер вышестоящего уровня, старая и новая организации и затронутые стороны. Контактная запись могла указывать, к кому обращаться. Решение о делегировании зависело от операционных характеристик, согласия, сообщений и пересмотра.

Это сравнение в пределах DNS. Оно не может установить право собственности на блок IP-адресов и не доказывает, что каждое изменение домена второго уровня проходило тем же процессом.

Завершённый случай административного статуса: CLUE.COM в 1996 году

Политика урегулирования споров о доменных именах Network Solutions от июля 1995 года предписывала уведомление и процедурные варианты для зафиксированного регистранта при предъявлении квалифицированного требования о товарном знаке. Более поздние описания этой политики сами по себе устанавливают процедуру, а не завершённую опору. Конкретный случай восполняет недостающее доказательство.

Решение 1998 года по делуOppedahl & Larson v. Network Solutionsописывает обстоятельства принятия политики июля 1995 года. Оно называет признания сторон, экспонат с политикой и реакцию политики на зарегистрированный федеральный товарный знак, идентичный зарегистрированному доменному имени. Регистратор мог написать регистранту домена и предложить определённые варианты. Этот судебный отчёт подтверждает процедуру, фиксируя также споры о её применении к существующим регистрантам.

Отдельное современное судебное разбирательство документирует применение политики к конкретной регистрации. В делеNetwork Solutions, Inc. v. Clue Computing, Inc.Окружной суд США округа Колорадо зафиксировал, что Clue Computing владела регистрацией CLUE.COM, управляемой Network Solutions, и что Hasbro заявила конкурирующее требование о товарном знаке.

1 февраля 1996 года Network Solutions уведомила Clue Computing, что использование домена может нарушать товарный знак Hasbro. Регистратор потребовал от Clue Computing либо предоставить сертификат на товарный знак, либо согласиться на назначение нового доменного имени. Clue Computing не осталась пассивным именем в отображении. Она ответила как признанный регистрант, подала иск в суд штата против Network Solutions и добивалась запрета на перевод регистрации в режим удержания.

25 июня 1996 года окружной суд округа Боулдер запретил Network Solutions изменять регистрацию и использование CLUE.COM. Тем временем Network Solutions подала федеральный иск об интерпледере, представив себя стейкхолдером, готовым передать регистрацию и использование по указанию суда. Федеральный суд отклонил этот иск. Он заключил, что существующий запрет суда штата не позволял Network Solutions передать домен под федеральный контроль и что спор также затрагивал договорные обязательства Network Solutions перед Clue Computing.

Доказательственные элементы необычайно полны:

• Дата:уведомление 1 февраля 1996 года, затем иск в суд штата, июньский запрет и федеральное решение в 1996 году.
• Субъекты действия:Network Solutions, Clue Computing, Hasbro, окружной суд округа Боулдер и федеральный окружной суд.
• Конкретная запись:регистрация CLUE.COM в авторитетной регистрационной системе Network Solutions вместе с файлом спора регистратора и конкурирующей подачей по товарному знаку.
• Решение:должен ли зафиксированный регистрант представить квалифицирующее доказательство, принять замену имени, столкнуться с удержанием или получить судебную защиту.
• Конкурирующие источники истины:регистрационная запись, доказательства товарного знака Hasbro, регистрационные отношения, фактическое использование, договорные обязанности и судебные приказы.
• Исход:зафиксированный регистрант получил уведомление, вступил в процедурный спор и добился запрета, сохранившего регистрацию на время разбирательства; федеральный интерпледер был отклонён.

Этот случай демонстрирует административный статус внутри базовой процедуры регистрации регистратора. Текущая регистрация определяла, какую сторону Network Solutions рассматривала как регистранта, чьё использование оспаривается и чей ответ имеет значение.

Он не показывает, что Network Solutions установила личность этой стороны исключительно путём публичного запроса WHOIS. Решение говорит об авторитетной регистрации, управляемой Network Solutions, политике регистратора, его переписке и последующем судебном разбирательстве. Публичный WHOIS мог раскрывать регистрационную и контактную информацию, но дело не устанавливает, что публичное отображение создало процедурную позицию Clue Computing.

Регистрация также не решила конечный вопрос о товарном знаке. Запись товарного знака Hasbro давала конкурирующее требование. Clue Computing опиралась на договорный и судебный процесс. Запрет сохранял статус-кво; это не было окончательным заявлением о том, что публичные контактные данные доказывают право собственности.

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

Столкновение октября 1995 года: мутация базы данных и практический контроль

Более поздний федеральный апелляционный материал по делуKremen v. Cohenреконструирует иное изменение регистрации в октябре 1995 года.

Network Solutions получила письмо, якобы уполномочивающее удаление существующей регистрации домена и регистрацию другой стороной. Действуя на основании письма, Network Solutions удалила прежнюю регистрацию из своей базы данных, зарегистрировала домен на другую организацию и указала нового административного контакта. Позже письмо было признано поддельным. Новый регистрант использовал домен. Когда потребовали восстановления, Network Solutions изначально требовала судебного приказа. Судебное разбирательство в конечном счёте привело к восстановлению регистрации.

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

Пять реальностей должны оставаться раздельными:

1. Авторитетная база регистраций:Network Solutions удалила одну регистрацию и внесла другую.
2. Публичный вывод WHOIS:запрос мог отображать информацию, производную от текущей регистрационной системы, но решение не говорит, что публичный запрос вызвал изменение.
3. Процедура изменения:Network Solutions действовала на основании поданного письма.
4. DNS и использование:за новой регистрацией последовало практическое использование домена.
5. Документальные и юридические доказательства:видимое разрешение противоречило подлинному согласию и позже было признано поддельным.

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

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

Это не доказывает, что публичный WHOIS сам по себе передал домен, наделил правом собственности или побудил Network Solutions действовать. В лучшем случае публичный ответ отражал бы изменённое состояние после транзакции. Конститутивная операция произошла в авторитетных системах регистрации и администрирования DNS.

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

Номер сети, ASN и контакт: запись номерного ресурса

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

Предшественник: сетевые контакты DDN

В отчёте Стал от апреля 1991 года описан файлNETWORK-CONTACTS— человекочитаемый файл зарегистрированных номеров интернет-сетей. Раздел 3.10, стр. 11 отчёта, гласит, что информация поступала из заявок на регистрацию интернет-номеров, обработанных хостмастером NIC, и исправлений, поданных сетевыми координаторами. Исходные данные хранились в базе данных NIC WHOIS. Производный файл генерировался еженедельно.

Контактный файл связывал номер сети и имя сети с контактом и хэндлом NIC. Его оперативная цель была ясна: перейти от номера к ответственной организации или лицу. Он не содержал полной переписки о выделении, соглашения с провайдером, доказательств использования или состояния маршрутизации.

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

Население InterNIC после апреля 1993 года

RFC 1400 помещал IP-адреса и номера автономных систем с соответствующими точками контакта в сервис InterNIC после перехода. Это формализовало объектно-центрированное население: человек всё чаще появлялся потому, что был связан с зарегистрированным инфраструктурным объектом.

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

RWhois как дизайн-сравнение

RFC 1714, датированный ноябрём 1994 года, предлагал протокол Referral WHOIS для распределённой среды реестров. Он различал авторитетные и кэшированные ответы, определял зоны авторитета и использовал серийные значения, менявшиеся при изменении данных. Он также допускал регистрационные операции и предусматривал информацию аутентификации.

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

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

RWhois, таким образом, является дизайн-сравнением 1994 года, а не свидетельством универсально развёрнутой системы аудита. Его серийные значения отслеживали состояние зоны авторитета; они не обязательно были публичным объяснением того, кто изменил каждый объект, на каком основании и зачем.

RFC 2050 и влекущие последствия регистрационные данные

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

Документ называл три причины таких подач:

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

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

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

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

Значимость записи для верхней ступени, таким образом, нормативна, а не привязана к конкретному случаю:

• Датированная политика:RFC 2050, ноябрь 1996 года.
• Субъекты действия, названные политикой:региональные реестры, локальные реестры, провайдеры и запрашивающие организации.
• Запись:данные выделения, назначения и переназначения.
• Решение:оперативный контакт и вопрос о том, оправдывает ли продемонстрированное использование дополнительное адресное пространство.
• Конкурирующие источники истины:назначения клиентам, доказательства использования, инженерные планы, таблицы маршрутизации, договоры с провайдерами, организационные документы и переписка с реестром.
• Указанное последствие:недостаточная информация о переназначении или обоснование могли повлиять на будущие выделения.
• Ограничение:источник не документирует конкретный файл выделения до 1997 года, в котором названный реестр принял и завершил такое решение.

RFC 2050 доказывает политическую связь между регистрацией и выделением. Без файла дела он не доказывает, насколько последовательно применялось правило или что публичный вывод WHOIS сам по себе решил конкретный запрос.

Пересмотр и конфиденциальность за пределами протокола запросов

RFC 2050 даёт два важных ограничения, которые центрированный на WHOIS взгляд может упустить.

Во-первых, раздел 6 давал организации право обжаловать решение реестра в родительском реестре. Назначающий реестр должен был предоставить соответствующую документацию. Дальнейшие апелляции могли идти вверх по иерархии и, после исчерпания других путей, к IANA для окончательного решения. Каждый реестр должен был документировать свою процедуру апелляции.

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

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

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

• Происхождение:провайдеры, локальные реестры или запрашивающие организации поставляли назначения и подтверждающие материалы.
• Право обновления:RFC 2050 налагал обязанности оперативной подачи, но не определял единый технический метод аутентификации каждого обновления.
• Аутентификация и проверка:реестры могли проводить аудит и требовать подтверждающую документацию; публичная запись не раскрывала все эти доказательства.
• Исправление и замена:окружающий процесс реестра мог пересматривать записи, но RFC 2050 не определял универсальной публичной истории версий.
• Время:требовалась оперативная подача; текущая публичная строка не обязательно раскрывала полную историю вступления в силу.
• Пересмотр:апелляции шли через иерархию реестров и могли в конечном счёте достигать IANA.
• Приватность:регистрация имела публичный оперативный компонент, тогда как информация, обозначенная заявителем как чувствительная, должна была оставаться конфиденциальной.
• Право:регистрация могла влиять на администрирование выделений, но не гарантировала маршрутизацию и не служила полным титульным инструментом.

Сравнение четырёх семейств записей

Общий интерфейс WHOIS скрывал разные доказательственные пределы.

Это сравнение предотвращает две ложные истории.

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

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

Лестница с обнажёнными пределами

Лестницу доказательств теперь можно проверить на датированном поведении, а не только на именах полей.

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

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

Откуда брался авторитет

WHOIS не приобрёл силу только через технический протокол.

RFC 812 гласил, что NIC SRI поддерживает сервис по поручению Агентства оборонных коммуникаций. В отчёте Стал от апреля 1991 года названы государственный контракт, ответственный подрядчик, результатный документ, исходная база данных и производные файлы. RFC 1400 документирует переход услуг non-DDN к InterNIC.

Юридическая история Счётной палаты правительства США (GAO)фиксирует, что Национальный научный фонд заключил кооперативное соглашение с Network Solutions в 1993 году о предоставлении расширенных и координированных информационных услуг для немилитарного Интернета. Эти услуги включали регистрацию доменов второго уровня, при этом Network Solutions также сотрудничала с USC в управлении корневой зоной.

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

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

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, IANA и региональные реестры были связанными учреждениями, но не взаимозаменяемыми. Их аудитории, назначенные функции, исходные материалы и записи менялись. Непрерывность данных не гарантировала, что каждая унаследованная запись была повторно аутентифицирована по процедурам преемника.

Исторически ограниченные издержки приватности и исправлений

Приватность входит в эту историю, потому что исходные поля были выбраны для доступности.

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

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

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

Запись также показывает сужение населения. RFC 1400 говорил, что индивидуальные записи InterNIC будут в основном охватывать точки контакта, связанные с активными узлами, тогда как общие проекты личных справочников могли распределяться в других местах. К 1996 году RFC 2050 различал публичную регистрационную информацию и чувствительный материал заявки, который реестры обязаны были хранить в тайне, если заявитель пометил его таковым.

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

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

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

Контрфактический сценарий A: аутентифицированные, версионированные и явно не конститутивные записи

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

Это ограниченное дизайн-сравнение. Контролируемые бумажные формы, сохраняемая переписка, процедуры обратного вызова, датированные журналы и институциональные встречные подписи были концептуально доступны в тот период. Универсальная криптографическая система идентичности, связывающая каждый сетевой контакт с организацией, не была установленным требованием RFC 812. Более поздние допущения о федеративной идентичности, автоматических сертификатах или структурированных сервисах регистрационных данных не следует проецировать назад как обязанности, которые разработчики 1982 года игнорировали.

В этих границах более сильные меры улучшили бы несколько решений.

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

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

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

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

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

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

Контрфактический сценарий B: нет справочника, а базовые отношения сохраняются

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

Многие решения остаются возможными.

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

Отсутствующая функция — быстрое обнаружение через институциональные границы.

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

В администрировании доменов DNS мог бы показывать работающие серверы имён, а регистрационная переписка — исходный запрос. Без общего справочника найти административного представителя было бы труднее. Работа DNS по-прежнему не доказывала бы организационное согласие.

В споре CLUE.COM Network Solutions могла бы идентифицировать своего регистранта из авторитетного регистрационного файла и переписки, даже если бы публичного сервиса WHOIS не существовало. Регистратор всё равно мог бы отправить уведомление, а регистрант — прибегнуть к договорным или судебным средствам. Это показывает, что административный статус в том деле не зависел исключительно от удобства публичного запроса.

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

Этот контрфактический сценарий выявляет отличительную ценность WHOIS: он делал разнородные отношения искомыми от идентификатора. Он вводил в поле зрения первое релевантное лицо или организацию.

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

Порог 1997 года

Институциональная история ARINгласит, что ARIN была создана в декабре 1997 года как независимая некоммерческая организация, предоставляющая услуги IP-регистрации в своём регионе. Еёгодовой отчёт за 1999 годдатирует начало операций 22 декабря 1997 года.

До этой даты несколько утверждений стали хорошо поддержанными:

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

Ряд более сильных утверждений остаются недоказанными рассмотренными здесь свидетельствами:

• что каждое обновление личных, хостовых, доменных или номерных ресурсов использовало единый метод проверки личности;
• что каждая публичная запись раскрывала полную историю прежних значений и причин изменений;
• что существующий публичный контакт автоматически обладал полномочиями подтверждать или заменять регистрацию;
• что первоначальный запрашивающий по RFC 1400 признавался из-за предыдущего публичного контактного упоминания;
• что публичный WHOIS сам по себе создал административный статус Clue Computing в споре 1996 года;
• что изменение регистрации по делу Kremen было вызвано опорой на публичный запрос WHOIS, а не процедурой изменения регистратора и мутацией базы данных;
• что публичная строка номерного ресурса сама по себе решила документированный запрос о выделении до 1997 года;
• что перечисленный контакт окончательно устанавливал текущий технический контроль, юридическое владение или договорное право;
• что делегирование DNS устанавливало право на блок IP-адресов;
• что более поздний региональный реестр вёл или создавал записи до начала своей работы.

Переход от удобства к авторитету, следовательно, не имел единой даты. Его сильнейшие этапы произошли в разных семействах записей.

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

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

Источники

• RFC 812 — NICNAME/WHOIS, 1 марта 1982 года
• RFC 954 — NICNAME/WHOIS, октябрь 1985 года
• RFC 1032 — Руководство администратора домена, ноябрь 1987 года
• RFC 1173 — Обязанности менеджеров хостов и сетей, август 1990 года
• Descriptions of NIC Tables and Lists — финальный отчёт SRI International, 5 апреля 1991 года
• Опыт безопасности Интернета в Италии — симпозиум USENIX Security 1992 года
• RFC 1400 — Переход и модернизация службы регистрации Интернета, март 1993 года
• RFC 1591 — Структура системы доменных имён и делегирование, март 1994 года
• RFC 1714 — Протокол Referral WHOIS, ноябрь 1994 года
• Network Solutions, Inc. v. Clue Computing, Inc. — Окружной суд США округа Колорадо, 1996 год
• Oppedahl & Larson v. Network Solutions, Inc. — Окружной суд США округа Колорадо
• Kremen v. Cohen — Апелляционный суд США девятого округа
• RFC 2050 — Правила выделения IP-адресов интернет-реестрами, ноябрь 1996 года
• Путеводитель по записям SRI ARC/NIC — Музей компьютерной истории, 2011 год
• GAO B-327398 — Правительственная юридическая история технических функций Интернета
• История ARIN — American Registry for Internet Numbers
• Годовой отчёт ARIN за 1999 год