Кратко

  • Клиент X может спонсировать удаляемые домен и хост, хотя домен клиента Y всё ещё использует этот хост как сервер имён.
  • Переименование, pendingDelete, уведомление, восстановление, окончательная очистка и возвращение DNS — разные события; один успешный ответ их не доказывает.

Команда удаления EPP выглядит локальной: спонсор просит убрать свой объект, сервер проверяет правила и отвечает. RFC 9874 показывает разрыв этой модели. X спонсирует домен и подчинённый ему хост, а Y связал тот же хост с другим доменом. X способен удалить свою связь, но не вправе изменить объект Y.

RFC 5731 рекомендует не удалять домен, пока с ним связаны подчинённые хосты. RFC 5732 защищает хост, связанный с другими объектами. Так аккуратная операция не превращается незаметно в отказ DNS. Но остаётся вопрос: как позволить X законно уйти, не заставляя его бессрочно поддерживать инфраструктуру Y?

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

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

Опубликованный как BCP 244, RFC 9874 выделяет три безопасных семейства. Клиент может поддерживать отдельный авторитетный жертвенный хост, сохраняя регистрацию родителя, адреса и реальный DNS. Сервер может явно удалить хосты и связи с деталями, уведомлением и возможностью восстановления. Наконец, сообщество может создать домен специального назначения; в таком случае рекомендован sacrificial.invalid. Документ не утверждает, что последние два способа уже развёрнуты.

При обратимом подходе домен, подчинённые хосты и междоменные связи остаются представленными во время pendingDelete. Публичный DNS уже может отказать, показывая будущий ущерб, а RFC 3915 ещё допускает восстановление до финальной очистки. Запрос, обратимое состояние, срок реакции и необратимое удаление требуют отдельных отметок времени.

Уведомление не равно исправлению. Сервер может показать инициатору затронутые объекты и применить change poll из RFC 8590 для других спонсоров. Создание сообщения не доказывает, что регистратор его прочитал, сообщил владельцу, исправил делегацию или вернул услугу.

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

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

DNSSEC снижает часть рисков, но не отменяет доказательство. Автоматика, принимающая CDS/CDNSKEY от одного захваченного сервера, может превратить несогласованность в более глубокую передачу контроля.

SAC125 и доклад IETF 115 Risky BIZness дают контекст рисков управления серверами имён. Они не доказывают нынешнюю уязвимость или поведение конкретного оператора. RFC 9874 — проектный ответ на класс риска, не отчёт об инциденте.

Источники