Кратко

  • draft-ranjbar-regext-rdap-subordinate-referrals-01 предлагает направленные отношения для обнаружения RDAP-сервиса, назначенного держателем для имён, сетей или адресов ниже зарегистрированного объекта.
  • Данные нижнего сервиса утверждает держатель, а не оператор реестра. Строгая подчинённость, обратная ссылка и предел в один переход ограничивают сферу; держатель при этом видит поступившие запросы.
  • Клиенту нужна запись стыка полномочий: покрывающий объект реестра, акт назначения и подчинённый ответ держателя должны оставаться разными свидетельствами.

Обычный путь RDAP начинается с загрузочных реестров IANA. Клиент находит сервис, ответственный за домен верхнего уровня или диапазон номерных ресурсов, и запрашивает самый конкретный объект, который хранит этот оператор. Путь выглядит единой цепочкой авторитета.

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

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

Проблема возникает, если интерфейс стирает место перехода.

Направление вниз не наследует статус реестра

Редакция 01 называет rdap-base-down отношение к базовому URL нижестоящего сервиса, а rdap-base-up — обратное отношение к базовому URL покрывающего реестра. Имена описывают направление между сервисами, не превращая нижнего оператора в реестр.

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

Получаются два утверждения. Реестр сообщает, что данный держатель назначил данный сервис для данного диапазона. Держатель затем сообщает содержимое подчинённой записи. Если приложение назовёт всё «данными реестра», факт назначения превратится в одобрение содержания.

Совместимость легко скрывает смену источника

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

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

draft-ietf-regext-rdap-referrals-04 задаёт явный запрос перенаправления к связанному RDAP-ресурсу. При единственной подходящей ссылке и разрешённом клиенте сервер возвращает HTTP-код перенаправления и Location. Проект учитывает выбор отношения, согласование, кэширование и цепочки. Он экономит передачу полной записи ради одной ссылки, но не решает, как подписывать голос конечного ответа.

Держатель становится источником и наблюдателем

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

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

Доступность также разделяется. Отказ сервиса держателя лишает дополнительных подчинённых данных, но не ответов самого реестра. Формулировка «RDAP недоступен» смешивает сбой реестра, неверный указатель и отказ нижнего сервиса — три инцидента с разными владельцами.

Назначение остаётся неописанным узлом власти

Проект не определяет, как держатель сообщает реестру выбранный сервер. Портал или будущая EPP-надстройка приведены как примеры. Для узкого RDAP-текста это понятно, однако административное право менять маршрут запроса остаётся за пределами формата.

Кто ставит, меняет и отзывает указатель? Может ли подрядчик, управляющий сервером, изменить назначение? Когда новая цель вступает в силу? Должна ли передача домена или номерного ресурса автоматически отменять старую? Какое доказательство остаётся после компрометации учётной записи?

Реестру рекомендуется проверить, что цель выдаёт соответствующий RDAP для ресурсов держателя. Соответствие не равно владению. Сервер способен вернуть идеальный JSON о чужом объекте. Нужен цикл: аутентифицированное создание, доказательство области, тест цели, активация, продление, изменение, отзыв и очистка после передачи.

Сохранять стык полномочий при получении

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

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

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

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

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

Отношения названы обобщённо, чтобы поддержать делегированный или гибридный RPKI и замену RWhois или SWIP. Это экономит словарь, но «ниже» обозначает топологию, а не юридический мандат, качество или гарантию сервиса.

Редакция 01 — индивидуальный Internet-Draft от 21 июля 2026 года. Datatracker не показывает формального статуса IETF, потока и предполагаемого статуса RFC, хотя заголовок говорит Standards Track. Автор предпочитает слияние с проектом REGEXT о перенаправлениях. Раздел реализации сообщает о сервисе на стороне держателя и называет отсутствующим переход на стороне реестра. Это не доказательство широкого внедрения.

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

Источники