Кратко

  • RFC 897 разделила переход к иерархическим именам и переход от HOSTS.TXT к распределённым серверам, поэтому новое имя могло обслуживаться старым механизмом.
  • RFC 921 сохранила прежний график и отметила выполненные вовремя, запоздавшие и ещё не выполненные пункты.
  • Серверы, данные, resolver, отдельные приложения и вывод таблицы из эксплуатации образовывали разные стадии, а для DDN/MILNET действовала отдельная траектория.

Центральная модель и раньше включала несколько шагов. RFC 810 задавала поддерживаемую NIC машиночитаемую таблицу хостов. Получатель должен был забрать файл, преобразовать его в местный формат и установить. RFC 811 описывала Hostnames Server для отдельных запросов и выдачи всей таблицы. Правильная запись у источника не доказывала, какую версию читала удалённая программа.

RFC 881 сформулировала ловушку внедрения. Как только несколько групп начнут посылать имена с точками, эти имена попадут в системы, которые ещё не готовы их обработать. Ожидание полной готовности всех делало начало нереальным. Поэтому доменная таблица должна была некоторое время существовать рядом с обычной, затем заменить её, а resolver — занять место прежнего библиотечного вызова так, чтобы большинство приложений не знало источник адреса.

RFC 882 и RFC 883 описали распределённые имена, типизированные данные, зоны, серверы, referrals, resolvers и caches. Готовая спецификация не была наблюдением того, что конкретный mailer перестал открывать локальный файл.

Новое имя могло жить в старой таблице

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

План состоял из четырёх ступеней: добавить .ARPA к старым именам, ввести несколько доменов, перейти от таблиц к серверам и разрешить множество доменов. Поэтому USC-ISIF.ARPA могло быть официальным именем, найденным в HOSTS.TXT. Точка показывала форму, а не путь запроса.

Старое имя разрешалось временно оставить как nickname. Это помогало узлу принимать обращения по alias, но не исправляло чужую адресную книгу, старые поля From, To и Cc или список рассылки на другой машине. После распространения имени часть состояния миграции принадлежала уже внешним держателям копий.

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

Одинаковая форма не создала одинаковой обязанности

RFC 897 назначила 14 марта 1984 года началом использования доменных имён как основных, 2 мая — концом старых имён, 6 июня — открытием общих многоуровневых доменов, 18 июля — организационных имён, 5 сентября — выводом полной таблицы для исследовательского сообщества ARPA и 3 октября — планом DDN.

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

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

Пересмотр не стёр пропущенные сроки

RFC 920 опубликовала требования к новым доменам и новый набор top-level domains только в октябре, хотя RFC 897 ожидала этот документ в феврале. Политика допуска формировалась во время развёртывания.

RFC 921 включила старый график с комментариями. Начальная доменная таблица и мартовская смена primary name были выполнены вовремя. Серверы ARPA появились, но к сентябрю, а не к апрелю. Таблица top-level domains, новые и многоуровневые домены, организационные имена, отказ от host table и план DDN ещё не были готовы.

Новый план разделил три фазы. Machinery означала servers и resolvers. Database — установленные данные. User programs — реальный переход mailers, Telnet, FTP и других программ. В октябре 1984 года машины продвинулись далеко, данные ARPA присутствовали, другие верхние домены были инициализированы, но пользовательские программы почти не изменились.

Новые даты тянулись до октября 1985 года. Они оставались целями, не подтверждением будущего. Ценность RFC 921 — в открытой классификации прошлого: сделано, сделано с опозданием, ещё не сделано.

Смешанный режим стал свойством приложения

В 1987 году RFC 1031 описывала в MILNET три одновременные стадии: только таблица, таблица вместе с DNS и только DNS. Telnet и FTP могли перейти раньше MAIL, либо первым мог стать MAIL. Даже один хост имел несколько фронтов миграции.

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

RFC 1034 позднее объяснила, почему распространение HOSTS.TXT не масштабировалось, и сохранила resolver interface, похожий на старую функцию. Совместимость позволяла менять backend без одномоментной переделки всех callers, но скрывала этот переход от поверхностного наблюдения.

RFC 1401 воспроизвела переписку 1992 года, где IAB называл переход MILNET незавершённым и связывал рассинхронизацию таблиц и DNS с отказами доступности. Это политическая аргументация, а не нейтральная количественная перепись. Но она документирует многолетний хвост отдельного пути.

Источники и пределы

Основа статьи — RFC 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 и 1401. Они подтверждают спецификации, обязанности, даты, самоаудит и поздние документальные заявления. Они не подтверждают единый мировой день перехода, соблюдение каждым сайтом, аутентификацию имени, нынешнюю доступность или поведение современного продукта.