Кратко

  • В SINS из RFC 830 доменная служба находила адрес конечного DNS/AIP, а отдельные Application Interface Processes согласовывали транспорт, прикладной протокол и совместимую услугу.
  • Источник шёл по меткам справа налево; каждый промежуточный DNS знал только непосредственных детей, мог иметь собственный формат данных, а кеширование оставалось выбором реализации.
  • RFC 882 и RFC 883 стандартизировали распределённую базу ресурсов с типами, классами, зонами, авторитетностью, ссылками, кешем и обновлением. Запись стала общей, но не превратилась в доказательство работающей возможности.

Распределить таблицу было недостаточно

HOSTS.TXT соединял имя и адрес в одной распространяемой копии. По мере роста сети централизованное обновление и доставка становились дорогими. Иерархия доменов предлагала естественное деление: каждый администратор отвечает за свой участок и непосредственных потомков.

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

RFC 830 выбрала второй вариант. Её System for Internet Name Service состояла из независимой от приложений доменной службы и интерфейса приложений. DNS разрешал доменную часть. AIP продолжал работу после того, как найден конечный домен.

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

Иерархия распределяла право на имена

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

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

RFC 830 логически связывала с каждым доменом DNS. Для надёжности функцию могли выполнять несколько серверов. В конечном домене рядом с DNS размещался AIP.

Адрес, полученный после разрешения домена, вёл к этому DNS/AIP. Он обозначал представителя административной области, но не обязательно конечный сокет нужной программы.

Источник начинал с правой метки

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

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

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

Базы конечных DNS содержали верхние домены, базы промежуточных — непосредственные поддомены. Наборы не пересекались и обновлялись локально. RFC 830 не требовала стандартного внутреннего формата: взаимодействие определялось протоколом на границе.

После адреса начинался разговор о возможностях

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

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

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

Ответ о несовместимости мог предложить другой протокол того же назначения. В примере источник просил удалённую передачу файлов через NIFTP. Назначение имело только FTP. Если источник тоже поддерживал FTP, стороны могли продолжить.

Альтернатива принадлежала источнику

Назначение сообщало доступную возможность, но не командовало источнику использовать её. Локальное приложение могло принять FTP вместо NIFTP или отказаться. Динамическое связывание сохраняло вариативность, не превращая сервер назначения в центрального планировщика.

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

Цепочка делилась на существование домена, достижение его DNS/AIP, объявление возможности, выбор адреса, транспорт, разрешение и результат приложения. Каждый факт имел собственный источник и время.

Если объединить их, ранний координатор получает лишнюю власть. Владелец записи начинает выглядеть владельцем услуги, а успешный поиск — одобрением действия. RFC 830 технически удерживала эти выводы отдельно.

Стандарт охватывал диалог, а не память

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

Протокол не зависел от транспорта, но для большинства коротких обменов TCP считался избыточным из-за установления соединения. UDP должен был вместить обычные команды; запрос повторялся в ответе для надёжного сопоставления.

Кеширование было признано необходимым для эффективности. Полное разрешение перед каждой транзакцией создавало бы лишний трафик. Однако RFC 830 не делала кеш стандартной функцией SINS и оставляла его реализации.

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

RFC 881 описала мост, а не конечную архитектуру

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

Эта схема позволяла перейти от одного файла к распределённым серверам. Она не требовала сохранять AIP-переговоры. RFC 882 и RFC 883 выбрали иное содержание общего слоя.

Имя стало ключом к набору ресурсных сведений. Запрос указывал тип, а класс различал семейства протоколов и форматы. Серверы имён держали авторитетные зоны и ссылки. Резолверы следовали ссылкам и кешировали ответы.

Авторитетная информация происходила из зон и главных файлов. Кеш происходил из прошлых запросов и истекал по таймерам. Форматы ресурсов, запросы, перенос зон и обновление стали стандартными частями распределённой базы.

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

DNS перенёс общий смысл в данные

RFC 1034 упоминает RFC 830 среди ранних предложений иерархических имён. Проектом, который после опыта реализаций превратился в позднейший DNS, она называет распределённую базу и обобщённые ресурсы RFC 882 и RFC 883.

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

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

Неосуществлённая граница RFC 830 полезна именно этим различием. Распределить имя недостаточно; нужно решить, где живёт изменчивая способность. Какой бы слой ни был выбран, его ответ нельзя повышать до власти над следующими этапами.

Источники