Кратко

  • Клиент X может управлять доменом и подчинённым host, но не иметь права менять домен клиента Y, который зависит от этого host для DNS.
  • Переименование в якобы свободное внешнее имя или адреса неавторитетного рекурсивного сервиса переносит риск отказа и перехвата; RFC 9874 запрещает такие наблюдавшиеся практики.
  • Межклиентская квитанция должна отдельно связывать полномочия, охват, состояние DNS, предупреждение, уведомление, срок redemption, restore и окончательный асинхронный purge.

Клиент X закрывает domain1.example. Внутри него существует ns1.domain1.example. Но domain2.example, спонсируемый клиентом Y, тоже указывает на этот сервер имён. X не может обновить объект Y и может не видеть полную связь. Реестр видит обе стороны.

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

Почему ограничения на удаление важны

RFC 5731 рекомендует не удалять домен, пока с ним связаны подчинённые host. RFC 5732 рекомендует не удалять host, пока он связан с другими объектами. Эти предостережения защищают DNS: без вышестоящего домена имя host может перестать разрешаться, а без host зависимые делегации теряют сервер.

Они также защищают согласованность клиента и сервера. Если сервер неявно удаляет связи, клиент хранит устаревшую картину. Наконец, они защищают целостность отношений во внутренней базе реестра.

Межклиентский случай добавляет разделение власти. X вправе завершить свой объект. Y вправе управлять своей делегацией. Сервер решает, станет ли конфликт запретом, переименованием, отсоединением или обратимым переходом.

У sacrificial host всегда есть хранитель

Переименование выводит host из удаляемого домена и сохраняет его как внешний. Но новое имя не нейтрально.

Если родительский домен лишь считается несуществующим, его может зарегистрировать злоумышленник. Создав соответствующий host, он получит запросы доменов, которые всё ещё ссылаются на старую зависимость. RFC 9874 говорит, что такую наблюдавшуюся практику использовать нельзя.

Glue на адреса известного публичного рекурсивного DNS не делает его авторитетным. Возможны SERVFAIL и интенсивные повторные запросы. Эта практика также запрещена.

Допустимый вариант требует, чтобы клиент удерживал родительский домен sacrificial host и обслуживал авторитетный DNS на указанных адресах. Это предотвращает чужой захват, но создаёт долгую обязанность: продление, lock, мониторинг и передача ответственности при реорганизации. Переименование не уничтожает зависимость — оно назначает ей нового хранителя.

Redemption превращает удаление в управляемый процесс

Вторая модель разрешает явное удаление и обработку связей с объектами других клиентов. Сервер может заранее показать детали воздействия, потребовать осознанное подтверждение и уведомить затронутых через EPP Change Poll.

Согласно RFC 3915, домен, подчинённые host и связи могут оставаться в pendingDelete в течение redemption-периода. Изменение уже отражается в DNS, но граф можно восстановить. Ошибочное, злонамеренное или неожиданно разрушительное действие допускает restore до крайнего срока. Затем следует окончательный purge.

Число ассоциаций не ограничено, поэтому отключение, возврат и очистка могут выполняться асинхронными частями. Время принятия команды и время завершения последней связи — разные факты.

Квитанция повторяет границу полномочий

Первый блок хранит аутентифицированного клиента, transaction ID, объект, время, политику сервера и основание для межклиентского воздействия. Второй фиксирует снимок зависимостей: метод и время перечисления, подчинённые host, число доменов и клиентов, а также пределы видимости.

DNS-блок показывает авторитетные имена и адреса до и после, ожидаемое и наблюдаемое состояние зоны, условия DNSSEC и DS, выбранную практику RFC 9874. Блок решения сохраняет предупреждения, предоставленные детали, ручное одобрение и обоснование.

Для других клиентов нужны постановка уведомления в очередь, доставка и подтверждение без раскрытия частных данных регистранта. Обратимость доказывают крайний срок, полномочие restore, сохранённые связи и тест восстановления. Асинхронный хвост закрывают task ID, частичные сбои, повторы, финальный purge и проверка DNS.

Это рекомендация Daniel Kade, а не новое поле EPP и не требование RFC. Конфиденциальность допускает счётчики и непрозрачные ссылки, но не отсутствие доказательства, что зависимости были учтены.

DNSSEC зависит от согласованности источников

DNSSEC и несколько серверов могут снизить риск, но не исправляют плохую смену хранения. RFC 9874 описывает ситуацию, когда злоумышленник контролирует один сервер, а автоматическое обслуживание DS принимает CDS/CDNSKEY без проверки согласованности всех авторитетных ответов. Материал атакующего может попасть в DS, а CSYNC — усилить замену.

Следовательно, квитанция должна назвать активную DS-автоматизацию, опрошенные серверы, согласованность ответов и полномочие, принявшее изменение. Метка «DNSSEC включён» не является доказательством безопасного перехода.

Один результат не заменяет пять выводов

RFC 9874 рекомендует поддерживаемый клиентом авторитетный sacrificial host, явное удаление с деталями, уведомлением и restore либо подходящий special-use domain. Практики, перекладывающие затраты на третьих лиц, не рекомендуются.

Удаление остаётся допустимым. Но нужно различать: сервер принял команду; зависимости перечислены; затронутые уведомлены; восстановление доступно; очистка закончена. Для каждого вывода требуются свои часы и доказательства. Иначе успех для X может стать необъяснимым инцидентом для Y.

Источники