Кратко

  • RFC 849 отделил актуальность главного файла NIC от актуальности локальных копий, которыми сайты действительно пользовались.
  • Предпочтённая схема отдавала скорость однократной отправке, а восстановление — дешёвой проверке версии при запуске и периодическому опросу.

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

Главный файл при этом может быть совершенно правильным. Несоответствие возникает не в реестре, а на пути от опубликованного состояния к исполняемому.

Этому промежутку посвящён RFC 849, Suggestions for Improved Host Table Distribution, опубликованный Mark Crispin в мае 1983 года. Автор сразу предупредил: ни одно из предложений не является стандартом. Документ буквально запрашивал комментарии, надеясь, что общий вывод позднее приведёт к норме. Поэтому он не доказывает внедрение описанного протокола. Он доказывает другое: проблема свежести уже требовала разделить несколько видов свидетельств.

Единый источник не создавал единого рабочего состояния

RFC 608 описывал раннюю модель: NIC хранит исходные данные и периодически, например раз в неделю или по необходимости, формирует из них ASCII-файл имён, адресов и свойств. Получившийся <NETINFO>HOSTS.TXT можно забрать по FTP.

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

В 1982 году RFC 810 задал новый формат для DoD Internet. Таблица охватывала сети, шлюзы, хосты, операционные системы и отдельные протоколы. Её можно было получить анонимным FTP с SRI-NIC либо через Host Name Server. Но пользователь отвечал за преобразование таблицы в формат, нужный его локальной системе.

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

RFC 811 добавил работающий сервис на TCP-порту 101. Команда HNAME искала по имени, HADDR — по адресу, а ALL возвращала всю таблицу между BEGIN и END. Доступ к данным NIC стал удобнее, но дешёвого ответа на вопрос «моя установленная копия той же редакции?» всё ещё не было.

Без номера версии молчание имело два значения

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

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

Второе предложение RFC 849 состояло в протоколе, который сообщал текущую «version» таблицы. Для Tenex и TOPS-20 естественным идентификатором был номер поколения файла. Crispin уже хранил SYSTEM:HOSTS.TXT с тем же поколением, что у NIC, и время от времени проверял, изменилось ли удалённое число. Он хотел автоматизировать эту проверку.

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

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

Полный push требовал помнить чужие отключения

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

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

RFC 849 также предложил checksum, чтобы убедиться, что обновлённый реестр пришёл полностью и без повреждений. Границу этого свидетельства нельзя расширять. В документе не было криптографической аутентификации источника, защиты от злонамеренной подмены или доказательства истинности записей. Целостность передачи, полномочия отправителя, содержательная правильность и локальное применение — разные утверждения.

Почта доставляла объект, но не активное состояние

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

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

Четвёртая схема использовала запуск как точку самопроверки

Предпочтение Crispin отдал сочетанию отправки и проверки версии. NIC один раз пошлёт обновление зарегистрированным хостам и не будет бесконечно вести повторные попытки. Каждый сайт при запуске системы опросит NIC, проверит наличие новой редакции и при необходимости заберёт её. Дополнительный периодический опрос — например, ежедневный — станет резервом.

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

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

Мгновенной сходимости схема не обещала. NIC мог оказаться недоступен при запуске; передача могла оборваться; checksum — не совпасть; преобразование — завершиться ошибкой; старая база — остаться активной. Достоинство было в том, что эти случаи больше не скрывались за одной отметкой «HOSTS.TXT обновлён». У каждого была наблюдаемая граница и следующее действие.

Распределение не отменило время распространения

В ноябре 1983 года RFC 881 всё ещё отмечал, что почти все хосты Internet пользуются той или иной таблицей на основе главного HOSTS.TXT NIC. План ввода доменных имён предусматривал период сосуществования.

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

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

Реален последний завершённый переход

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

RFC 849 оставил последовательность доказательств: редакция источника, попытка уведомления, принятые байты, подтверждённая целостность, завершённое преобразование, наблюдаемое активное состояние и независимое восстановление. Каждая ступень отвечает на свой вопрос.

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

Источники