Кратко

  • RFC 3375 описал общую систему регистрации, где несколько регистраторов управляли спонсируемыми объектами, но для конкретного пространства имён и зоны авторитетным оставался один реестр.
  • Идентичность объекта, спонсорство, связь с общим ресурсом, перенос, состояние транзакции и публикация DNS были разными фактами. Успешный ответ одного уровня не доказывал завершение следующего.

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

RFC 3375 вышел в сентябре 2002 года со статусом Informational. Это не Internet Standard и не обследование внедрений. Документ формулировал требования к общему протоколу между реестром и регистраторами, способному поддерживать разные операционные модели в период становления конкурентной регистрации.

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

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

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

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

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

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

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

Граница с DNS особенно важна. RFC 1034 и RFC 1035 описывают зоны, авторитетные серверы, кэширование и разрешение имён. RFC 2136 задаёт отдельный механизм динамического обновления зоны. RFC 3375 говорит об объектах реестра и относит создание файлов зон к функциям реестра. Продление или изменение контакта может успешно пройти без изменения DNS. Принятое изменение делегирования ещё проходит проекцию, распространение, загрузку и влияние кэшей до публичной видимости.

Ранее RFC 2832 определил Registry Registrar Protocol. Затем RFC 3730 специфицировал EPP; позднее RFC 5730 заменил его базовую спецификацию, а RFC 5731, RFC 5732 и RFC 5733 описали отображения доменов, хостов и контактов. Эта последовательность показывает совершенствование интерфейса, но не доказывает всеобщего внедрения или одинакового времени публикации.

Нормативные слова RFC 2119 также требуют осторожности. MUST устанавливает требование к проекту протокола, а не удостоверяет реальное исполнение каждым оператором. Политика интернационализации RFC 2277 напоминает, что символы, человеческие языки, контактные сведения и DNS-идентификаторы были взаимосвязанными, но не тождественными задачами.

Идея Лу Хэна о минимальной начальной спецификации объясняет институциональный выбор: совместно закрепить лишь необходимое для взаимодействия, оставив последующие решения ответственному контексту. Его модель слоёв реальности задаёт метод проверки. Запрос владельца, разрешение регистратора, спонсорство, приём реестром, состояние хранилища, создание зоны, авторитетный сервис и наблюдение резолвера образуют цепь, но не один взаимозаменяемый факт.

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

Источники