Кратко

  • В редакции 05 RDAP DELEG исключены priority и target, структура переименована в DelegInfos, а примеры согласованы с DELEG-11.
  • Проект отображения EPP, на который RDAP ссылается нормативно, по-прежнему содержит оба атрибута в XML-схеме, названной полной и пригодной для автоматической проверки.
  • Текст RDAP уже требует идентификатор соответствия dnsDeleg, хотя полное описание пар ключ—значение в JSON отмечено как TBD.
  • Источники не показывают развёрнутой системы или реальной потери данных. Они показывают отсутствие проверяемого кругового пути EPP—DNS—RDAP в текущих редакциях.

Публичная сторона уже изменилась

Объявление I-D фиксирует выпуск draft-albanna-regext-rdap-deleg-05 4 сентября 2026 года. Проект предлагает включать значения DELEG и DELEGPARAM в RDAP-ответы о доменных объектах. Он не создаёт новую делегацию, а описывает, как показать связанные данные пользователю регистрационного сервиса.

История изменений прямо перечисляет три шага: удалены ссылки на priority и target, имя delegInfo заменено на DelegInfos, примеры основаны на DELEG-11. В DELEG-11 сказано, что при сходстве с форматом SVCB новый формат не имеет SvcPriority и TargetName. Его содержимое — список пар DelegInfo.

Начальный набор включает server-ipv4, server-ipv6, server-name и include-delegparam, а также метаключ mandatory. Для будущих ключей предлагается отдельный реестр IANA с номером, названием, значением, стабильной ссылкой и контролёром изменений. Расширяемость тем самым должна оставаться общей, а не превращаться в набор частных диалектов.

Редакция RDAP последовала этому решению. На стороне чтения старые поля больше не представлены.

Входная схема осталась на прежнем шаге

RDAP-проект опирается не только на DELEG, но и нормативно ссылается на отображение DELEG в EPP. Через EPP спонсирующий клиент создаёт, изменяет и запрашивает доменный объект в реестре. Предлагаемое расширение дополняет доменное отображение, установленное RFC 5731.

EPP DELEG-02 называет раздел формального синтаксиса полной схемой для автоматической проверки XML. В типе delegType всё ещё определены атрибут priority типа unsigned short и атрибут target. Тип параметров также допускает произвольные атрибуты с processContents="skip".

Календарь предлагает простое объяснение. EPP-02 датирован 21 июля, DELEG-11 — 23 июля, а RDAP-05 — сентябрём. Однако редакционное отставание не отвечает системе, что делать. Ввод может быть допустим по опубликованной EPP-схеме и содержать два поля, которых, согласно актуальному DELEG, уже нет и которые актуальный RDAP сознательно убрал.

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

dnsDeleg не раскрывает цепочку происхождения

RDAP-05 требует помещать dnsDeleg в rdapConformance, когда возвращается новая структура. RFC 9083 определяет такие строки как указатели на спецификации, использованные при построении ответа. Клиент может распознать расширенный JSON, но не узнать из одного ярлыка происхождение значения и предыдущую политику преобразования.

Именно здесь текст пока не завершён. Полное определение ключей и значений DelegInfos помечено TBD; авторы ждут развития DELEG и EPP. Примеры дают представление о форме, но не связывают нормативно EPP XML, представление и wire-формат DNS и RDAP JSON.

На момент фиксации исследования в реестре расширений RDAP IANA не было dnsDeleg. Проект просит зарегистрировать его для оператора “Any”. Отсутствие не означает отказ IANA; это лишь состояние ещё не зарегистрированного предложения.

Отдельный проект REGEXT о версионировании RDAP предлагает машинно-читаемые версии, связи между предшественником и преемником, сведения об устаревании и политику перехода. RDAP DELEG-05 пока не использует этот механизм, чтобы назвать точную версию своей нагрузки.

Статус основного документа не передаётся спутникам

Datatracker RDAP DELEG показывает индивидуальный Internet-Draft без RFC stream и ответственного Area Director. EPP-отображение также индивидуально. Опубликовать I-D может любой автор; публикация не равна одобрению IETF.

DELEG-11 — документ рабочей группы DELEG на стадии Working Group Last Call. Но это всё ещё проект: номера DNS RR и новый реестр ключей содержат запрашиваемые или неопределённые значения. Более высокий процедурный статус основы не превращает две ссылки в принятые стандарты.

Поэтому точная формулировка — открытый, вероятно исправимый стык. Для слов «уязвимость», «отказ» или «повреждение» доказательств нет.

Нужна карта сохранения смысла

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

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