Кратко

  • В комментарии от 16 октября ICANN просят привести оценку автоматизации записей DS в DNSSEC в соответствие с RFC 10026 — уже опубликованным руководством IETF.
  • Июньский отчёт в одном разделе требует останавливать автоматизацию при блокировке на стороне реестра, но позднее допускает продолжение работы самого реестра. Обязательное требование HR-4 прямо описывает только блокировку у регистратора.
  • ICANN рассмотрит замечания и может обновить оценку. Срок подачи заканчивается 23 ноября, доклад по комментариям ожидается 7 декабря; окончательного решения и текста договора пока нет.

Вопрос не в том, нужна ли автоматизация DNSSEC. Речь о том, какого участника ограничивает статус блокировки, когда меняется запись DS в родительской зоне. Именно это уточнение предложено в комментарии к оценке ICANN по безопасности и стабильности автоматизации DS.

Quynh Nguyen в обращении от 16 октября считает, что оценка охватывает основные риски, но должна последовательно описать serverUpdateProhibited. Автор подаёт комментарий от собственного имени; это не вывод ICANN и не позиция, выраженная консенсусом сообщества. Однако трактовка может повлиять на готовящийся Fast-Track в рамках Registry Services Evaluation Policy (RSEP): ICANN намерена использовать оценку как техническую основу для операторов реестров, которые хотят автоматизировать обслуживание DS.

Отчёт Interisle Consulting Group датирован 23 июня 2026 года. В разделе 4.4 он принимает позицию, что автоматическое обслуживание DS следует приостанавливать при активном serverUpdateProhibited. Там же описана противоположная позиция проекта IETF, рассматривавшегося на тот момент: при автоматизации со стороны реестра этот статус требует от EPP-сервера отклонять запросы регистратора на изменение данных, но не запрещает реестру выполнять собственные действия.

В июле проект стал RFC 10026 — документом Best Current Practice 246. Пункт 6.1(2) говорит, что реестр не должен приостанавливать автоматизацию DS только из-за serverUpdateProhibited. В разделе 6.2.1 поясняется разделение ролей: блокировка мешает регистратору направить изменение по EPP, но не отключает автоматизацию реестра; уведомление регистратора позволяет ему узнать о такой операции.

Противоречие есть и внутри самой оценки. Раздел 4.7 допускает работу при clientUpdateProhibited и serverUpdateProhibited, а раздел 6.1 также говорит, что эти статусы не требуют останавливать плановое обслуживание, если регистратор может отказаться от автоматизации со стороны реестра. При этом HR-4 прямо устанавливает лишь, что одного clientUpdateProhibited недостаточно для приостановки. Nguyen просит сформулировать единое правило в соответствии с RFC 10026.

Есть и более поздний ориентир. 31 августа комитет SSAC опубликовал SAC126v2, обновив рекомендацию с учётом RFC 10026. Комитет указал, что стандарт разрешил вопрос из раздела 4.4 предыдущей версии, а SAC126v1 выведен из обращения. Таким образом, июньская оценка появилась до публикации RFC и обновлённой рекомендации SSAC.

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

На странице консультации ICANN говорится, что организация опубликует сводку комментариев, рассмотрит их и может выпустить обновлённый отчёт с дополнением. Срок заканчивается 23 ноября 2026 года; доклад должен выйти 7 декабря. Проект договорных условий для Fast-Track будет обсуждаться отдельно. Ни оценка, ни этот комментарий не являются разрешением на запуск и не определяют будущие условия договора.

Источники