Кратко

  • ICANN спрашивает, выявляет ли оценка безопасности и стабильности автоматизации DNSSEC-записей DS риски и предлагает ли достаточные, соразмерные и выполнимые меры.
  • Положительный вывод оценки обусловлен семью обязательными требованиями и семью раскрываемыми оператором параметрами. Это не универсальное разрешение на любое внедрение.

Эффект регистрационных блокировок — конкретный вопрос, который ICANN предстоит решить до ускорения процедуры DNSSEC. Объявление о публичном обсуждении устанавливает срок и предмет рассмотрения.

Датированная 23 июня оценка объёмом 41 страницу рассматривает конкретную схему. Оператор дочерней DNS-зоны публикует записи CDS или CDNSKEY; родительская сторона — обычно реестр или регистратор — проверяет сигнал и может изменить запись DS в родительской зоне. В документе описаны поддержание существующей цепочки доверия, первоначальная настройка и переход к делегированию без DNSSEC. Push-уведомления, внешние API и CSYNC исключены. Поэтому вывод не распространяется на все способы менять делегирование и не подтверждает безопасность реализации конкретного оператора. Отчёт Interisle считает, что при выполнении условий схема не создаёт значительной проблемы безопасности или стабильности.

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

Ещё семь параметров оператор должен документировать: периодичность сканирования, предельную задержку, политику для нескольких подписантов и адресатов уведомлений, среди прочего. Четыре рекомендуемые практики дополняют список, но не являются условием положительного вывода.

Такое разделение отличает общий минимум от решений, зависящих от внедрения. Согласованность ответов серверов имён, установленная RFC 9975, обязательна. Частота проверок, канал уведомлений и срок отката выбираются оператором. Эти решения важны для того, сколько может сохраняться несовместимая DS-запись и кто узнает об отклонённом или неудачном обновлении. Оценка указывает, что рассматриваемые RFC не задают единого механизма оповещения обо всех результатах. Проверяемость технического сигнала сама по себе не гарантирует, что владелец домена увидит, что произошло.

Временная последовательность даёт отдельный вопрос для комментариев. Оценка датирована 23 июня, а RFC 10026 в июле получил статус Best Current Practice IETF. Текущая страница ICANN уже включает RFC 10026 в справочные материалы, тогда как текст оценки с июньской датой сохраняет прежнюю хронологию проекта. RFC 10026 рассматривает проверки принятия сигнала, отчётность, блокировки регистрации и конкурирующие обновления. Это не отменяет июньскую работу автоматически. Но участники могут спросить, как семь требований и семь раскрываемых параметров соотносятся с опубликованным BCP 246 и какие доказательства должны сопровождать будущую заявку.

Расхождение видно в разделе оценки о блокировках. Документ принимает позицию SAC126: статус serverUpdateProhibited должен останавливать автоматизацию со стороны реестра, тогда как один лишь clientUpdateProhibited не должен её останавливать. Окончательный RFC 10026 придерживается противоположного подхода к блокировке реестра: автоматизацию самого реестра нельзя приостанавливать только из-за этого статуса, который реестр может переопределить. Отказ регистратора от автоматизации остаётся способом выразить противоположное предпочтение. Сводный перечень жёстких требований прямо регулирует блокировку клиента, но не содержит параллельного правила для блокировки реестра. Поскольку текущая страница ICANN ссылается на RFC 10026, участники могут спросить, какое правило будет применяться к будущим заявкам и договорным условиям.

Совет ICANN в сентябре 2025 года поручил создать ускоренный RSEP-путь для операторов реестров при условии отсутствия значимых проблем безопасности или стабильности. Регистраторы были выделены отдельно: им не требуется разрешение ICANN для запуска сервиса. RSEP сохраняет предварительное решение и возможность направить вопрос технической комиссии. Следовательно, оценка задаёт общую техническую основу для будущих заявок, но не одобряет конкретного оператора и не вводит новую договорную норму. Решение совета и политика RSEP устанавливают эти границы.

Участники могут проверить три положения: соответствуют ли обязательные требования действующему BCP; объясняют ли раскрытия сроки, уведомления и восстановление; и сохранит ли будущий договорный текст проверку конкретной архитектуры. Поскольку проект поправок появится после нынешней консультации, сводка от 7 декабря и следующий процесс будут разными свидетельствами того, как оценка превращается в порядок допуска. Общий перечень полезен, только если позволяет сравнивать заявки и при этом не скрывает различия между ними.