Кратко

  • draft-brown-epp-deleg-03 предлагает операции EPP для чтения, создания, добавления, точечного удаления и полного удаления DELEG-записей домена.
  • Проект ожидает длительного сосуществования DELEG и традиционных NS, поэтому корректное состояние объекта в реестре ещё может породить два несогласованных публичных представления делегации.
  • Надёжная квитанция следует за изменением от EPP через генерацию зоны, публикацию в родителе, DNSSEC и авторитативные серверы до возможностей резолвера, кэша и прикладной проверки.

В журнале регистратора есть идентификатор успешной транзакции. На панели DNS есть успешный запрос NS. Эти два зелёных поля не отвечают на главный вопрос: какой набор делегации получил резолвер, умеющий работать с DELEG?

Редакция 03 предлагаемого EPP-отображения DELEG делает этот пробел видимым. Она заменяет прежний синтаксис повторяющимися именованными элементами deleg:param, повышает версию пространства имён, добавляет deleg:all для полного удаления и вводит эксплуатационные требования. Карточка Datatracker и история редакций задают границу утверждений: это активный индивидуальный Internet-Draft без RFC stream, а не принятый стандарт и не свидетельство внедрения.

Транзакция заканчивается в репозитории

У проекта три поверхности управления. Ответ info может показать сохранённое представление DELEG. Команда create может внести одну или несколько записей вместе с новым доменом. Команда update может добавить запись, удалить точное совпадение или с помощью deleg:all убрать весь набор. Так можно доказать, какую мутацию сервер принял.

RFC 5730 определяет команды, ответы и идентификаторы транзакций EPP. RFC 5731 описывает отображение доменных объектов, а RFC 5732 — объектов хоста. Положительный ответ является ценной квитанцией серверной операции. Он не выдан генератором зоны, подписывающим компонентом, авторитативным сервером или рекурсивным резолвером.

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

Сосуществование требует сверки, а не предположения

Проект EPP исходит из того, что большинству доменов в обозримом будущем понадобятся одновременно DELEG и традиционные NS в родительской зоне. Серверы должны допускать DELEG рядом с EPP-объектами или атрибутами хостов. Это не замена одного столбца другим, а двойная проекция для двух групп потребителей.

Базовый проект рабочей группы Extensible Delegation for DNS пытается устранить старое расхождение между NS в родителе и на дочерней вершине. DELEG задуман как авторитетное, расширяемое и защищаемое DNSSEC представление в родителе. При этом DELEG RRset разрешён как с NS, так и без него. Если NS отсутствует, программное обеспечение без поддержки DELEG не сможет разрешить делегированную зону.

Поэтому у deleg:all нет единственного операционного смысла. Это может быть запланированный возврат к NS, отмена эксперимента или неполное либо несанкционированное изменение, которое NS-монитор не заметит. Синтаксис команды точен; её результат определяется состоянием обеих проекций.

Сопутствующий проект DNSOP о протокольных изменениях для новых типов делегации описывает согласование возможностей и защиту от downgrade. EPP-сервер не может засвидетельствовать правильное выполнение этого протокола авторитативными серверами и резолверами лишь потому, что сохранил объект.

У словаря параметров своя версия

Редакция 03 требует отклонять неизвестное имя параметра и синтаксически неверное значение. В пределах одной DELEG-записи имена уникальны. Клиент и сервер также должны периодически обновлять список зарегистрированных DelegInfoKeys.

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

Базовый проект DELEG просит IANA создать реестр Delegation Information, а проект EPP — зарегистрировать пространство имён и расширение. RFC 7451 задаёт механизм регистрации, а действующий реестр расширений EPP IANA показывает фактические назначения. В зафиксированном для исследования состоянии предлагаемого расширения DELEG там нет. Просьба в Internet-Draft не равна назначению.

В родительской зоне начинается вторая половина изменения

Базовый проект запрещает ставить DELEG на вершине дочерней зоны: неправильное место способно вызвать ошибку проверки DNSSEC. RFC 4035 описывает контекст аутентификации и валидации DNS. Успешная проверка подтверждает свойства полученного RRset в рамках цепочки. Она не подтверждает, что набор соответствует последнему EPP-намерению или что NS и DELEG ведут одинаково.

Проверяемый журнал начинается до XML. В нём названы намерение владельца, лицо или система с правом его выразить, идентичность клиента, точные байты запроса, пространство имён, снимок DelegInfoKeys и обе транзакционные метки. Затем фиксируются записанная версия объекта и правило согласования DELEG с хостами и NS.

После репозитория следуют вход и выход генератора зоны, serial родителя, подпись и результат загрузки каждого относящегося к делу авторитативного сервера. Нужны наблюдения по DELEG-способному и традиционному путям. Для резолвера сохраняются версия, сигнал возможностей, результат согласования, валидация, эпоха кэша и fallback. Последними идут прикладной canary и явное решение продолжить либо откатить.

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

Зафиксированные официальные источники

Пакет сохраняет текущую карточку Datatracker, её историю, точный текст редакции 03, проекты DELEG и DELEXT, спецификации EPP для ядра, доменов и хостов, реестр расширений, валидацию DNSSEC и живой реестр IANA. Ни один источник не доказывает работу конкретной реализации, транзакции или услуги.